Re: [gentoo-dev] Possible Change in Glibc Versioning

[Ned Ludd]

On Fri, 2004-04-23 at 16:17, Travis Tilley wrote:

snipped for sanity of the people being added to the CC:
...
..
.

Wise man said careful what one rants about..

> to backpedal a bit: SSP. why is this forced onto all users of all archs
> regardless of whether or not they intend to use SSP?

It's in __libc_start_main() because thats where it needs it be.
If it's symbols were move out of there then we are looking at reopening
alot of bugs that are currently resolved because of it being in glibc vs
libgcc_s.
 
We are not the only distribution that does this, we were just the 
first linux distribution ;-)

We are talking about 3 symbols here. 
All of which if we really needed to could be worked around rather
trivially. Something like so if we ever wanted to remove it. But I
HIGHLY recommend we not even try to explore this avenue at this time.

unsigned long __guard;
void __stack_smash_handler() {}
void __guard_setup() {}

Do these symbols keep you up at night?

..

> I dont really like this.
> I'd suggest a "nossp" USE flag, but at this point that isn't even possible!
> any removal of SSP from glibc will cause every single application on every
> single gentoo install to break horribly with errors about missing
> __guard@glibc.


Are you so sure of this? 
I was not aware that a dependency on the guard 
would be there unless you were actually using -fstack-protector or
-fno-stack-protector-all.

Please provide me with a valid test case that proves otherwise.
Allow me to demonstrate in a simple example.

solar@simple c $ cat main.c
int main(int argc, char **argv) { return 0; }

# Without ssp enabled.
solar@simple c $ gcc -fno-stack-protector main.c -o main
solar@simple c $ nm main | grep guard

# And with ssp.
solar@simple c $ gcc -fstack-protector-all main.c -o main
solar@simple c $ nm main | grep guard
         U __guard@@GLIBC_2.3.2


> we are now dependant on it and can never move away without
> some seriously hardcore pain. also,

Is there a valid reason to move away from it? 

Does anything else allow us to offer multi arch compiler technologies
(pointer, function verification) for our binaries thats stands up on
it's technical merits as high as ssp without a serious performance hit?

Do the research and you will probably come to the same conclusion as 
many us have.. period point blank it rocks our socks off for prevention
of ret2libc attacks but it's not limited to just that.

http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf
http://www.securityfocus.com/archive/1/269246

> it might be a bit more of a concern for
> embedded system users who might need to use a libc other than glibc and start
> off using non-static apps linked against glibc...

Peter S. Mazinger has already put this support together for uClibc.
In short it's not really a problem at all for embedded systems.
If and when a we get a report of somebody having problems with say
dietlibc then it's no problem to patch the stubs in there as well.

Got *libc ssp problems? Come talk to the doctor.

> but i'm not really familiar
> with embedded.

> there are probably many more issues here that i just havent
> realised yet, but for what reason were we pushed into this?

Well documented in our bugzilla.. 
Have a peek some time, search in the FIXED!

>
> Travis Tilley <lv@g.o>
> Gentoo/AMD64 Developer
>
> --
> gentoo-dev@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo Linux Developer