On Mon, Jul 11, 2016 at 7:34 AM, Dave Hansen <dave@xxxxxxxx> wrote: > On 07/10/2016 09:25 PM, Andy Lutomirski wrote: >> 2. When thread A allocates a pkey, how does it lock down thread B? >> >> #2 could be addressed by using fully-locked-down as the initial state >> post-exec() and copying the state on clone(). Dave, are there any >> cases in practice where one thread would allocate a pkey and want >> other threads to immediately have access to the memory with that key? > > The only one I can think of is a model where pkeys are used more in a > "denial" mode rather than an "allow" mode. > > For instance, perhaps you don't want to modify your app to use pkeys, > except for a small routine where you handle untrusted user data. You > would, in that routine, deny access to a bunch of keys, but otherwise > allow access to all so you didn't have to change any other parts of the app. > > 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. 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. -- 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>