public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Andrew Savchenko <bircoph@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Hardening a default profile
Date: Sat, 17 Jun 2017 14:43:24 +0300	[thread overview]
Message-ID: <20170617144324.d814f5c31189c785bafc72bc@gentoo.org> (raw)
In-Reply-To: <874lvgoitk.fsf@kestrel.kyomu.43-1.org>

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

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).

[1] https://bugs.archlinux.org/task/18864

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-06-17 11:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-11 21:39 [gentoo-dev] Hardening a default profile Michael Brinkman
2017-06-15 14:39 ` Tiziano Müller
2017-06-15 15:20 ` Matthias Maier
2017-06-16  0:05   ` Anthony G. Basile
2017-06-16  0:52     ` Matthias Maier
2017-06-17 11:43       ` Andrew Savchenko [this message]
2017-06-17 12:23         ` Alexis Ballier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170617144324.d814f5c31189c785bafc72bc@gentoo.org \
    --to=bircoph@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox