| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
What's New in Fedora Core 5 Test2
What's New in Fedora Core 5 Test2
Posted Jan 19, 2006 10:21 UTC (Thu) by nix (subscriber, #2304)Parent article: What's New in Fedora Core 5 Test2
The stack-protector has long been available as a patch by Hiroaki Etoh, but it operated by directly mangling raw RTL and was pretty much completely nonportable as a consequence (crashing GCC on SPARC, for instance): the feature in GCC 4.1 is a reimplementation by Richard Henderson and others.
However, the ABI used at runtime to call e.g. the stack-guard checks *has changed*, which means that any code compiled with -fstack-protector with the old patches *must be recompiled*, and if your libc includes a copy of the old stack guard code (as Gentoo's does), you'll have to take it out of there. (glibc-2.4 includes the new stack guard code, so FC5 is fine. This is hardly surprising given how many people @redhat.com were involved in the reimplementation :) )
(Log in to post comments)
What's New in Fedora Core 5 Test2
Posted Jan 19, 2006 10:34 UTC (Thu) by nix (subscriber, #2304) [Link]
The old patch was called, variously, `SSP' and `ProPolice' at different times (and by different people? Its history is murky.)
`Assign a random and verifiable value to the stack' is a bad description. It populates a random `stack canary' from /dev/urandom at process initialization, then puts it at the top of the stack frame of all functions containing a char array above a certain size (or, with -fstack-protector-all, any function containing a char array); it also reorders the stack frame to ensure that parameters also appear on one side of the canary, while the function return address is on the other side of it. The effect is to ensure that buffer overruns that smash the return address will always smash the canary too, making `return-into-libc' attacks and many other classes of buffer overrun much harder.
(The only downside is that this drains /dev/urandom's entropy pool. gentoo at least has a patch that creates a /dev/frandom device that is seeded just once from the entropy pool and then becomes a normal PRNG, and a patch to SSP that uses it, but the frandom patch was rejected from the kernel tree on the basis that some daemon could equally well do the job. It could: but that would stop you from using it in SSP...)