From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 73708139694 for ; Sat, 17 Jun 2017 12:23:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 296F6E0C58; Sat, 17 Jun 2017 12:23:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D2DF2E0BF0 for ; Sat, 17 Jun 2017 12:23:36 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e34:eeaa:6bd0:4ecc:6aff:fe03:1cfc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 1622D3418D3 for ; Sat, 17 Jun 2017 12:23:34 +0000 (UTC) Date: Sat, 17 Jun 2017 14:23:29 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Hardening a default profile Message-ID: <20170617142329.6939fc75@gentoo.org> In-Reply-To: <20170617144324.d814f5c31189c785bafc72bc@gentoo.org> References: <878tktnupm.fsf@kestrel.kyomu.43-1.org> <60680dd3-b243-cfe7-43ce-50361cd4c65e@gentoo.org> <874lvgoitk.fsf@kestrel.kyomu.43-1.org> <20170617144324.d814f5c31189c785bafc72bc@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 22ecf21e-73c3-4146-8866-5b27069c4a8b X-Archives-Hash: edaf0d44ad5bca770b2651308b1470e9 On Sat, 17 Jun 2017 14:43:24 +0300 Andrew Savchenko 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