Messages in this thread | | | Subject | Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls | From | Dave Hansen <> | Date | Mon, 11 Jul 2016 08:48:00 -0700 |
| |
On 07/11/2016 07:45 AM, Andy Lutomirski wrote: > On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen <dave@sr71.net> wrote: >> Should we instead just recommend to userspace that they lock down access >> to keys by default in all threads as a best practice? > > Is that really better than doing it in-kernel? My concern is that > we'll find library code that creates a thread, and that code could run > before the pkey-aware part of the program even starts running.
Yeah, so let's assume we have some pkey-unaware thread. The upside of a scheme where the kernel preemptively (and transparently to the thread) locks down PKRU is that the thread can't go corrupting any non-zero-pkey structures that came from other threads.
But, the downside is that the thread can not access any non-zero-pkey structures without taking some kind of action with PKRU. That obviously won't happen since the thread is pkeys-unaware to begin with. Would that break these libraries unless everything using pkeys knows to only share pkey=0 data with those threads?
> So how is user code supposed lock down all of its threads? > > seccomp has TSYNC for this, but I don't think that PKRU allows > something like that.
I'm not sure this is possible for PKRU. Think of a simple PKRU manipulation in userspace:
pkru = rdpkru(); pkru |= PKEY_DENY_ACCESS<<key*2; wrpkru(pkru);
If we push a PKRU value into a thread between the rdpkru() and wrpkru(), we'll lose the content of that "push". I'm not sure there's any way to guarantee this with a user-controlled register.
| |