Re: [gentoo-dev] Hardening a default profile

[Alexis Ballier <aballier@gentoo.org>]

On Sat, 17 Jun 2017 14:43:24 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> On Thu, 15 Jun 2017 19:52:07 -0500 Matthias Maier wrote:
> > > there should be a way of turning these off systematically.  the
> > > advantage of the current hardened gcc specs is that one can switch
> > > between them using gcc-config.  if these are forced on for the
> > > default profile then there will be no easy way to systematically
> > > turn them off.  
> > 
> > No - there won't be an easy way for systematically turning off
> > SSP and PIE in 17.0 profiles [1,2].
> > 
> > The hardened toolchain with its different gcc profiles came from a
> > time where SSP and PIE were relatively new security features and a
> > certain amount of fine-grained control was needed. Further, at that
> > time we were talking about external patches against gcc. Nowadays
> > everything is upstreamed and (almost) no patches to gcc for
> > hardened profiles are applied any more.
> > 
> > Given the fact that all major linux distributions are following the
> > path of improved default hardening features (see for example [1])
> > and that we have been using ssp/pie in hardened profiles for years
> > now the purpose of fine-grained control over ssp/pie is also highly
> > questionable.
> > 
> > The consensus at the moment is that PIE and SSP (as well as stricter
> > linker flags) will soon be standard (or, actually *are* already
> > standard) compilation options. A per-package override (if
> > absoluetely needed) is fine - and, in fact, already in place
> > everywhere where needed.  
> 
> Gentoo is all about choice, remember? :)
> 
> It is really good to have them by default, it is bad to force them
> on everyone. Security is not always of paramount importance
> comparing to other factors, sometimes performance matters more,
> e.g. in isolated and restricted non-public HPC environment.
> 
> PIE, SSP may lead up to 8% of performance loss[1]. The
> stack-protector (especially stack-protector-all or -strong) may
> cause even more damage. For compute nodes this may be equivalent to
> millions USD loss (depends on the system scale of course).

This can probably be fixed by a gcc-config target disabling those as it
used to be the case on hardened