* Dave Hansen <[email protected]> wrote:
> On 07/11/2016 12:35 AM, Ingo Molnar wrote:
> > * Andy Lutomirski <[email protected]> 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
