Created attachment 358566 [details, diff] 09_all_default-ssp.patch Consensus on gentoo-dev is that we should enable -fstack-protector by default. I looked at a few different distro's SSP patches and decided to go with Debian's approach. It works with our ESP patchset and unlike most others handles the issue of SSP not being available on some archs. I've tested that the patch handles the different hardened gcc-config profiles correctly. The default adds -fstack-protector-all and hardenednopiessp, hardenednossp, and vanilla all use -fstack-protector. Beyond building it and playing with the options I've haven't done any other testing yet so YMMV. Outstanding issues: - the pie patchset has a "hack" for gcc-specs-* and _filter-hardened() for flag-o-matic. this is required for stuff like `filter-flags -fstack-protector`. I don't understand how this works or what the hell _gcc-specs-directive_raw() is doing. Can someone explain it? - 03_all_gcc48_Makefile.in.patch in the ESP patchset adds -fno-stack-protector to BOOT_CFLAGS, LIBCFLAGS and LIBCXXFLAGS. Is that required because of -fstack-protector-all or is it needed for -fstack-protector too? (I don't see it in other distro's ssp patches) - the ESP patchset drops -fstack-protector-all when -nostdlib or -nodefaultlibs are used. Debian uses -nostdlib or -ffreestanding. - should we also disable SSP with -D__KERNEL__ or rely on the kernel's build system to add -fno-stack-protector when CONFIG_CC_STACKPROTECTOR is disabled? - ssp-buffer-size is reduced from the default 8 bytes to 4. Most distros do this, so I kept it in. - the glibc SSP core handler patches. I think these are unrelated? - glibc common.eblit has: use hardened && gcc-specs-ssp && append-cflags $(test-flags-CC -fno-stack-protector) Once gcc-specs-ssp works "hardened" will have to be dropped from this.
(In reply to Ryan Hill from comment #0) > Created attachment 358566 [details, diff] [details, diff] > 09_all_default-ssp.patch > > Consensus on gentoo-dev is that we should enable -fstack-protector by > default. > > I looked at a few different distro's SSP patches and decided to go with > Debian's approach. It works with our ESP patchset and unlike most others > handles the issue of SSP not being available on some archs. > The patch is applay only if the arch support it check debian/rules.patch. Uclibc have problems if is not build with tls and nptl #470608 > I've tested that the patch handles the different hardened gcc-config > profiles correctly. The default adds -fstack-protector-all and > hardenednopiessp, hardenednossp, and vanilla all use -fstack-protector. > > Beyond building it and playing with the options I've haven't done any other > testing yet so YMMV. > > Outstanding issues: > > - the pie patchset has a "hack" for gcc-specs-* and _filter-hardened() for > flag-o-matic. this is required for stuff like `filter-flags > -fstack-protector`. I don't understand how this works or what the hell > _gcc-specs-directive_raw() is doing. Can someone explain it? > In short the gcc-specs-directive_raw() make a specdump and include any sub spec rules and spec files that get included and sort out the stacking order of the spec rules. gcc-specs-ssp grep the raw cc1 spec rule for "!fno-stack-protector:". All the gcc-specs-* was before my time and when i move the hardened spec rules from the cc1/link_command spec, i still needed to support gcc 3.X that still did have the old way so i added the hack for the cc1 spec so the fuctions should work for the new spec rules to dectect if the compiler was hardened or not. > - 03_all_gcc48_Makefile.in.patch in the ESP patchset adds > -fno-stack-protector to BOOT_CFLAGS, LIBCFLAGS and LIBCXXFLAGS. Is that > required because of -fstack-protector-all or is it needed for > -fstack-protector too? (I don't see it in other distro's ssp patches) > if you look in the debian/rules2 file you will see that it get added if ssp is enable > - the ESP patchset drops -fstack-protector-all when -nostdlib or > -nodefaultlibs are used. Debian uses -nostdlib or -ffreestanding. > -nodefaultlibs is something that was added under the time with kevquinn and psm that did alot of the gcc 4.X work and it was before my time. If you want some more reading you should look in the README file in the piepatch. -ffreestanding should be added to be on the safe side. > - should we also disable SSP with -D__KERNEL__ or rely on the kernel's build > system to add -fno-stack-protector when CONFIG_CC_STACKPROTECTOR is disabled? > I would add check for -D__KERNEL__ to be on the safe side. We did use that before the kernel did support ssp. > - ssp-buffer-size is reduced from the default 8 bytes to 4. Most distros do > this, so I kept it in. > > - the glibc SSP core handler patches. I think these are unrelated? > > - glibc common.eblit has: > > use hardened && gcc-specs-ssp && append-cflags $(test-flags-CC > -fno-stack-protector) > > Once gcc-specs-ssp works "hardened" will have to be dropped from this. You only need to add "%{!fno-stack-protector: }" to cc1 spec to make gcc-specs-ssp work.
i'm not sure why we should go this route when we already have the specs logic. isn't it as simple as always doing the minispec logic and then changing the default specs profile to hardenednopie ?
Well, the SSP hardened is using is -fstack-protector-all, so that's what hardenednopie would get you (and -fstack-check... maybe some other goodies). I don't know how hard it would be to add another ssp-light spec to just do -fstack-protector or if that is a good idea, but I don't see how always installing hardened minispecs + people using non-hardened profiles selecting them = win. I see this as any other patch changing a default option. This one just happens to do it using a spec rule. It might be possible to do it using GCC_SPECS and a custom spec file but I'm not sure why that would be preferable and wouldn't have time to write it if it was. :/
(In reply to Ryan Hill from comment #3) afaik, the point of minispecs was to make it easy to add fragments the reason i think this route is preferable is: - the hardened team is already using this - we have just one code path (we just always enable minispecs) for building and patching which makes live easier for us (toolchain & hardened) - it'd allow users & devs to easily switch their system between variations ssp-all should not be the default for non-hardened builds due to its overhead in trivial functions. the Chromium OS project has adopted a third SSP variant called "strong": http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html and they're keeping it up-to-date, so that'd be nice for us to adopt too.
Hardened, you guys want to work on this?
Created attachment 366644 [details, diff] Change make_gcc_hard in the toolchain eclass so we pass ssp as defult Have change so it add -DEFAULT_SSP and move the needed sed's for the Makefile.in
Created attachment 366646 [details, diff] Updated default_ssp patch Have added needed -fno-stack-protector and a check for -DEFAULT_SSP
Going the Debian/Ubuntu way is the best way without messing to mutch around on patches and toolchain.eclass i think. What i have done is add the needed -fno-stack-protector on BOOT_CFLAGS, LIBCFLAGS and LIBCXXFLAGS but we may need to move that to new patch and add it to EPATCH_EXCLUDE, if we can't have it on all arches. I use hardened_gcc_works() that check SSP_STABLE or SSP_UCLIBC_STABLE from the ebuild to define what arch can have ssp on as default. We pass -DEFAULT_SSP with the help of sed's and the makefile.in. In the default_ssp patch i have added a check for the -DEFAULT_SSP so it enable the ssp spec. Haven't add -D__KERNEL__ and the needed stuff for gcc-specs-ssp to the patch. Do we want a nossp gcc gcc-config option?. Toolchain is this something we should move on or use a diffrent approch? Haven't added the updated pie patches. We have stop useing the minispecs from gcc 4.4.4 and forward. The spec in gcc did change alot and to minisise the patches changes and to support sparc we move it to DRIVER_SELF_SPECS and it is the way it will be past to upstream. Ssp on Uclibc will have problems if is not build with tls and nptl #470608.
Created attachment 366682 [details, diff] Update default_ssp with gcc-specs-ssp support Have updated the patch to support gcc-specs-ssp
Have added the needed default-ssp patch to the gcc 4.8.2 gentoo patchset dir and updated the piepatch dir with the needed changes to support ssp as default.
Stuff is commited to cvs.
Yeah, that needed at least a revision bump and a news item. Please revert 4.8.2 back and add a 4.8.2-r1 that's package.masked. I'll write the news item and send it to the list. You made sure the eclass changes don't affect older versions right?
Have done the revbump to -r1, mask and removed the keywords (In reply to Ryan Hill from comment #12) > Yeah, that needed at least a revision bump and a news item. Please revert > 4.8.2 back and add a 4.8.2-r1 that's package.masked. I'll write the news > item and send it to the list. You made sure the eclass changes don't affect > older versions right? Have done the revbump to -r1, mask and removed the keywords Thats way i added the tc_version_is_at_least 4.8.2 thing and you still need the default ssp patch else you only get the sed's added that have been added by hardened for some time.
*** Bug 508420 has been marked as a duplicate of this bug. ***
Are you providing a way to disable, if the user wants, the stack-protector?
-fno-stack-protector. I think, but it's been a while, that USE=nossp might also work. Also, Magnus is making strong the default for 4.9.
Fixed in 4.8.3.
