On Tue, 2018-06-19 at 17:50 -0700, Andy Lutomirski wrote:

quoted

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@amaca
pita
l.net> wrote:

quoted

On Jun 19, 2018, at 10:07 AM, Kees Cook <keescook@chromium.
org>
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?

The compiler throw/catch is already handled similarly to how longjmp is
handled.

To summarize the dlopen() situation,

----
(1) We don't want to fall back like the following.  One reason is
turning off SHSTK for threads is tricky.

if ((dlopen() a legacy library) && (cet_policy==relaxed)) {
	/*
	 * We don't care if the library will actually fault;
	 * just turn off CET protection now.
	 */
	Turn off CET;
}

(2) We cannot predict what version of a library will be dlopen'ed, and
cannot turn off CET reliably from the beginning of an application.
----

Can we mandate a signal handler (to turn off CET) when ((dlopen is used
) && (cet_policy==relaxed))?

quoted

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?

Ok, got it.

Yu-cheng
--
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