On Mon, 24 Oct 2011 13:26:01 +0200 ""Paweł Hajdan, Jr."" <phajdan...@gentoo.org> wrote:
> On 10/24/11 12:58 PM, Anthony G. Basile wrote: > > Well not totally on their own, they'd report it and we'd have to see > > what we want to do on an ad hoc basis. > > Fair enough, that's why I suggested to make the hardened spec > non-default, so that they have to switch it, and include the info in > emerge --info so we can identify the reason. > > > So maybe the first step would be > > to just build 5 specs: > > > > [1] x86_64-pc-linux-gnu-4.4.5 > > [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie > > [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp > > [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp > > [5] x86_64-pc-linux-gnu-4.4.5-vanilla > > > > Here [1] = fully hardened. Then ship with no other changes. When bug > > start to come in, you can deal with each --- some may be fixes at the > > package level (usually the build system), some may be ebuild fixes, some > > may need to go into the profiles. > > Right, this is exactly what I'm suggesting, just make [5] the default or > do some juggling so that [1] is vanilla and [5] is fully hardened or > something like that. I would expect x86_64-pc-linux-gnu-4.4.5 to be the vanilla profile and the fully hardened one to be something like x86_64-pc-linux-gnu-4.4.5-hardened. > > There is one other catch Zorry pointed out, glibc. There are some > > patches against glibc which would have to go in unconditionally. Take a > > look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently > > they're if use hardened. That conditional would be removed. > > Ah, ok. So we have another one. Let's find out our exact constraints: > > 1. Are those glibc patches required for gcc built with hardened support? > Will the gcc build fail without them, or will things fail at runtime > without them? > > 2. Enabling glibc patches would mean enabling PIC by default, right? Is > that OK? Can it cause breakages? > > 3. Am I reading things correctly that PIE is _not_ enabled by default, > but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs? I imagine they're conditional for a reason. I just don't know what that reason is myself. ;) > >> Third - can we forcefully disable hardened features in packages that are > >> not compatible? My assumption is yes, and we should probably print a > >> warning then. > > > > There are a few things you can do here, yes. It is always possible to > > turn off hardening because the *last* resort solution is just switch > > compile specs in the ebuild. > > Do you mean calling gcc-config here or something else? If gcc-config, > it'd be quite hacky and fragile (parallel building of multiple packages, > having multiple versions of gcc installed). > > Is it possible to just pass flags to GCC: disable all this hardened > stuff? I know you can disable stack protector, but how about PIE or PIC, > and possible other hardening features? You might be able to use the GCC_SPECS env var. Personally I think this is a lot of work for not much benefit, but if you want to do it then who am I to argue. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
