[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e152e1a7-e3b1-c3c4-ce1a-874e97300b37@redhat.com>
Date: Tue, 19 Jun 2018 08:40:53 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...nel.org>
Cc: "H. J. Lu" <hjl.tools@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Yu-cheng Yu <yu-cheng.yu@...el.com>,
LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
Linux-MM <linux-mm@...ck.org>,
linux-arch <linux-arch@...r.kernel.org>, X86 ML <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
"Shanbhogue, Vedvyas" <vedvyas.shanbhogue@...el.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Jonathan Corbet <corbet@....net>,
Oleg Nesterov <oleg@...hat.com>, Arnd Bergmann <arnd@...db.de>,
mike.kravetz@...cle.com
Subject: Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack
On 06/19/2018 02:52 AM, Kees Cook wrote:
> Adding Florian to CC, but if something gets CET enabled, it really
> shouldn't have a way to turn it off. If there's a way to turn it off,
> all the ROP research will suddenly turn to exactly one gadget before
> doing the rest of the ROP: turning off CET. Right now ROP is: use
> stack-pivot gadget, do everything else. Allowed CET to turn off will
> just add one step: use CET-off gadget, use stack-pivot gadget, do
> everything else. :P
>
> Following Linus's request for "slow introduction" of new security
> features, likely the best approach is to default to "relaxed" (with a
> warning about down-grades), and allow distros/end-users to pick
> "forced" if they know their libraries are all CET-enabled.
The dynamic linker can tell beforehand (before executing any user code)
whether a process image supports CET. So there doesn't have to be
anything gradual about it per se to preserve backwards compatibility.
The idea to turn off CET probably comes from the desire to support
dlopen. I'm not sure if this is really necessary because the complexity
is rather nasty. (We currently do something similar for executable
stacks.) I'd rather have a switch to turn off the feature upon process
start. Things like NSS and PAM modules need to be recompiled early. (I
hope that everything that goes directly to the network via custom
protocols or hardware such as smartcards is proxied via daemons these days.)
Thanks,
Florian
Powered by blists - more mailing lists