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 74B621382C5 for ; Mon, 16 Apr 2018 09:14:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A9391E098A; Mon, 16 Apr 2018 09:14:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5CBCCE0980 for ; Mon, 16 Apr 2018 09:14:43 +0000 (UTC) Received: from pc1 (unknown [IPv6:2001:2012:127:3e00:b3bf:56a1:a140:6086]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hanno) by smtp.gentoo.org (Postfix) with ESMTPSA id 06A8B335C77 for ; Mon, 16 Apr 2018 09:14:40 +0000 (UTC) Date: Mon, 16 Apr 2018 11:14:33 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Regarding the State of PaX in the tree Message-ID: <20180416111433.7ea80289@pc1> In-Reply-To: <8afcc662-4ca4-bf0b-d23a-cba93746ed70@gentoo.org> References: <8afcc662-4ca4-bf0b-d23a-cba93746ed70@gentoo.org> X-Mailer: Claws Mail 3.16.0 (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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: dd8608a5-3e9e-4e6b-a7b2-4a1ab75006ce X-Archives-Hash: 93a2ca64fcc8ec172ecfded3f5d98268 Hi, I honestly don't see how it would be feasible to maintain a feature that the developers maintaining it have access to. I get that this whole pax-thing embodies a huge part of Gentoo history and it may feel hard for some to let it go. But things are how they are. Regarding the fork states: I followed up on minipli's fork, which tried to maintain newer patches of grsec for LTS kernels, but that essentially stopped after KPTI/meltdown/retpoline. From what I know there's no public grsec patch with kpti or any spectre fixes, thus I would very much say you're safer these days with an upstream kernel. I think the only realistic way this support can be upheld would be if some people who have access to the grsec sources commit to making sure that it is maintained. There's also another question related to this: What's the future for Gentoo hardened? =46rom what I can tell hardened consists of: * the things that try to make it compatible with grsec/pax (more or less obsolete). * things that are now in default profiles anyway (aslr, stack protector). * things that probably should be in default profiles (relro, now linker flags) * -fstack-check, which should eventually be replaced with -fstack-clash-protection (only available in future gcc's) and that should probably also go into default profiles. * Furthermore hardened disables some useful features due to their incompatibility with pax (e.g. sanitizers). So it's stuff that either is obsolete or probably should be a candidate for main profiles. Maybe we should strive for "hardened-by-default". --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42