Thread (45 messages) 45 messages, 6 authors, 2016-07-18

Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

From: Ingo Molnar <mingo@kernel.org>
Date: 2016-07-12 07:13:17
Also in: linux-api, linux-arch, lkml

* Dave Hansen [off-list ref] wrote:
On 07/11/2016 12:35 AM, Ingo Molnar wrote:
quoted
* Andy Lutomirski [off-list ref] wrote:
mprotect_pkey()'s effects are per MM, but the system calls related to managing the 
keys (alloc/free/get/set) are fundamentally per CPU.

Here's an example of how this could matter to applications:

 - 'writer thread' gets a RW- key into index 1 to a specific data area
 - a pool of 'reader threads' may get the same pkey index 1 R-- to read the data 
   area.

Same page tables, same index, two protections and two purposes.

With a global, per MM allocation of keys we'd have to use two indices: index 1 and 2.
I'm not sure how this would work.  A piece of data mapped at only one virtual 
address can have only one key associated with it.
Yeah, indeed, got myself confused there - but the actual protection bits are per 
CPU (per task).
Remember, PKRU is just a *bitmap*.  The only place keys are stored is in the 
page tables.
A pkey is an index *and* a protection mask. So by representing it as a bitmask we 
lose per thread information. This is what I meant by 'incomplete shadowing' - for 
example the debug code couldn't work: if we cleared a pkey in a task we wouldn't 
know what to restore it to with the current data structures, right?

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help