Discussions: http://archives.gentoo.org/gentoo-dev/msg_ef3dbd4ba400a5936cd5b7546b86d875.xml http://archives.gentoo.org/gentoo-dev/msg_12996a4e4b107bb62f5cb6422c1ee12b.xml We need hardening in glibc first, see: http://archives.gentoo.org/gentoo-dev/msg_83bb7280932e97db87aa9cf44ba0ad1c.xml http://archives.gentoo.org/gentoo-dev/msg_1ada974856e02d36c8fd89436aa72b7a.xml I've successfully unmasked hardened USE flag and re-emerged glibc with USE=hardened. Could you remove hardened from glibc's IUSE and just always apply the hardening? A slightly more cautious option would be to unmask the hardened USE flag for glibc and ask more people to test it.
no, we're not going to build all of glibc as PIC/PIE by default without actual data to show it being worth the pain. certainly on x86, this is never going to happen.
(In reply to comment #1) > no, we're not going to build all of glibc as PIC/PIE by default without actual > data to show it being worth the pain. certainly on x86, this is never going to > happen. Could you please just unmask the hardened USE flag for glibc then? I think it's usable if people want to try it. I noticed your objections about PIC/PIE by default in the discussion, and I definitely think they apply to gcc. I'm not sure if USE=hardened has the same effect on glibc, especially with vanilla gcc. I got a message that it's not enabling PIE with my gcc. Furthermore, I'm not sure if building _just_ glibc with PIC (assuming that's really being done, I'm not sure) would have as big effect on system performance as building everything with it.
the hardened team maintains the profile. masking maintenance is up to them. iirc, USE=hardened in glibc does multiple unrelated things: ssp everywhere, custom ssp handler, PIC/PIE in all glibc code (even libc.a and friends).
Created attachment 290857 [details] build.log.gz Attaching build log for reference. Here's what I think is happening: -fPIC -DPIC gets applied to more or less everything -fpie -fstack-protector{,-all} gets applied only to nscd and pt_chown, should be negligible So of course on hardened profile USE=hardened is unmasked and enabled by default. My intention in this bug is to bring some of the hardening features to the default profile.
I chatted with zorry on #gentoo-hardened, and got his OK to unmask the hardened USE flag for >=glibc-2.13 just on amd64. I'll wait for "a while" in case of objections, but remember it's not even changing the defaults, it's just making the option available.
Okay I did a simple test to make sure things aren't going to go horribly bad. In a vanilla amd64 chroot, I unconditionally added the hardened patches to glibc and made sure it didn't break everything. Specifically: 1. Prepare a chroot based on stage3-amd64-20111020.tar.bz2 2. Hack sys-libs/glibc/glibc-2.12.2.ebuild, remove conditional if use hardend in eblit-src_unpack-post() 3. emerge glibc 4. emerge gcc binutils 5. emerge -e world No compile time breakage. I did not do many runtime test, beyond bash, perl, python, and whatever other utilities one typically uses in a chroot.
It's more complicated than I thought, closing for now.
