On 07/11/2016 07:45 AM, Andy Lutomirski wrote: > On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen <dave@xxxxxxxx> 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>