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

From: Ingo Molnar
Date: Tue Jul 12 2016 - 03:13:20 EST

* Dave Hansen <dave@xxxxxxxx> wrote:

> On 07/11/2016 12:35 AM, Ingo Molnar wrote:
> > * Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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?