GCC-4.x will have a new re-implemenation of the stack protector, provided upstream at least from GCC-4.1 (for backport to gcc-4.0 see bug #100689). New support for this will be required in libc; this bug is to record significant decisions/progress in support for glibc/uclibc and perhaps klibc. SSP support for the new implementation is provided by different symbols; although the support can be very similar, the new symbol names provide the ability to differentiate as necessary. Jakub Jelinek's changes for Redhat: http://sourceware.org/ml/libc-hacker/2005-06/msg00011.html some of which we may or may not want to modify/replace in glibc. Issues that come to mind that are under discussion so far include: 1) Use of syscall instead of libc calls in the guard setup and overflow handler, on linux kernels 2) Choice of random devices for the guard and implications from various kernel versions, especially w.r.t. having sufficient entropy and sufficient randomness, and also for workability in chroots. 3) Support on non-linux kernels
In case you didn't notice it, but I've been advertising this for the last two months. I've got a hardened gcc 4.0 toolchain running on x86, ppc and amd64 without any problems. I extracted the small changes between the gcc vanilla and RedHat's tree so that the SSP patch from the Fedora SRPM can be applied on top (and the other backported stuff too). And then the stuff in glibc and some modifications to toolchain.eclass so that it knows about gcc 4.x ssp. I also opened a bug about this some time ago: https://bugs.gentoo.org/show_bug.cgi?id=100689
Christophe, we're not ignoring you (far from it); your work on gcc-4.0 is appreciated. You'll see the first thing I wrote was a reference to your bug for gcc itself. This bug is specifically to track Gentoo modifications to the new ssp support as it integrates into the various _libc_ implementations. For the record here, glibc-2.3.5 branch update 20050722 contains the RedHat implementation of the SSP support into glibc, as of that date. See above for some items where we may wish to diverge.
Oh, sorry then. I didn't know how I managed to overlook that one. I'm pretty open to what you implement in glibc as long as you don't get ABI incompatible. I like that TLS is used for the stack guard when available, it's faster on some architectures than looking up the GOT pointer first and you can have a per-thread stack guard.
Well, lets bring this one back to life :) How far along is any of this? Or is gcc-4.1 still not ready for hardened?
Well, ssp support for gcc-4.1 is in glibc-2.4. However currently glibc-2.4 doesn't build with the hardened gcc - symptoms for me are the same as those reported on bug #94325; I'm still working on that. Also the move of __guard from libc.so to ld.so is going to cause some trouble. Also, whether it's worth back-porting to glibc-2.3.x I'm not sure. Probably not.
What kind of build problems are there? I've been using a hardened gcc 4.0 for about 4 months with glibc 2.3.90/2.4 and never had any problems with that. The gcc and glibc ebuilds in my overlay are initially based on Christophe's work. [1] i686-pc-linux-gnu-4.0.2-20051117 * [2] i686-pc-linux-gnu-4.0.2-20051117-hardenednopie [3] i686-pc-linux-gnu-4.0.2-20051117-hardenednopiessp [4] i686-pc-linux-gnu-4.0.2-20051117-hardenednossp [5] i686-pc-linux-gnu-4.0.2-20051117-vanilla [6] i686-pc-linux-gnu-4.1.0 GNU C Library development release version 2.4, by Roland McGrath et al. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.0.2-20051117 (Gentoo Hardened 4.0.2.20051117-r2, ssp-4.0-internal, pie-8.7.8). Compiled on a Linux 2.6.11 system on 2006-03-11.
Created attachment 82079 [details, diff] Patch Hm. It might be this patch that fixes it.
> Well, ssp support for gcc-4.1 is in glibc-2.4. However currently glibc-2.4 > doesn't build with the hardened gcc - symptoms for me are the same as those > reported on bug #94325; I'm still working on that. Also the move of __guard > from libc.so to ld.so is going to cause some trouble. glibc-2.4-r1 should rectify this situation
> glibc-2.4-r1 should rectify this situation glibc-2.4-r1 still fails to compile with hardened -- exact same errors as glibc-2.4 (multiple definition of `_itoa') as in bug #94325 (at least this is the case on AMD64)
> > glibc-2.4-r1 should rectify this situation > > glibc-2.4-r1 still fails to compile with hardened you're confusing things ... i said the __guard situation is fixed, i never said anything about being able to compile it with -fssp
Since glibc-2.4 now supports both the 3.x ssp and 4.x ssp, this can be closed, I think.
