Thread (98 messages) 98 messages, 13 authors, 2018-06-26

Re: [PATCH 06/10] x86/cet: Add arch_prctl functions for shadow stack

From: Andy Lutomirski <luto@amacapital.net>
Date: 2018-06-20 00:50:59
Also in: linux-arch, linux-mm, lkml

On Jun 19, 2018, at 3:38 PM, Yu-cheng Yu [off-list ref] wrote:

On Tue, 2018-06-19 at 13:47 -0700, Andy Lutomirski wrote:
quoted
quoted
On Jun 19, 2018, at 1:12 PM, Kees Cook [off-list ref]
wrote:
quoted
On Tue, Jun 19, 2018 at 10:20 AM, Andy Lutomirski <luto@amacapita
l.net> wrote:
quoted
On Jun 19, 2018, at 10:07 AM, Kees Cook [off-list ref]
wrote:

Does it provide anything beyond what PR_DUMPABLE does?
What do you mean?
I was just going by the name of it. I wasn't sure what "ptrace CET
lock" meant, so I was trying to understand if it was another "you
can't ptrace me" toggle, and if so, wouldn't it be redundant with
PR_SET_DUMPABLE = 0, etc.
No, other way around. The valid CET states are on/unlocked,
off/unlocked, on/locked, off/locked. arch_prctl can freely the state
unless locked. ptrace can change it no matter what.  The lock is to
prevent the existence of a gadget to disable CET (unless the gadget
involves ptrace, but I don’t think that’s a real concern).
We have the arch_prctl now and only need to add ptrace lock/unlock.

Back to the dlopen() "relaxed" mode. Would the following work?

If the lib being loaded does not use setjmp/getcontext families (the
loader knows?), then the loader leaves shstk on.  
Will that actually work?  Are there libs that do something like longjmp without actually using the glibc longjmp routine?  What about compilers that statically match a throw to a catch and try to return through several frames at once?

Otherwise, if the
system-wide setting is "relaxed", the loader turns off shstk and issues
a warning.  In addition, if (dlopen == relaxed), then cet is not locked
in any time.

The system-wide setting (somewhere in /etc?) can be:

   dlopen=force|relaxed /* controls dlopen of non-cet libs */
   exec=force|relaxed /* controls exec of non-cet apps */
Why do we need a whole new mechanism here?  Can’t all this use regular glibc tunables?--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help