[gentoo-dev] Re: Building hardened gcc specs always, just not enabling them by default

[Ryan Hill]

On Mon, 24 Oct 2011 13:26:01 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> 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