Re: MPK: removing a pkey

[Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]

On 11/23/2017 01:42 PM, Vlastimil Babka wrote:
>> It's supposed to set 0.
>>
>> -1 was, as far as I remember, an internal-to-the-kernel-only thing to
>> tell us that a key came from *mprotect()* instead of pkey_mprotect().
> So, pkey_mprotect(..., 0) will set it to 0, regardless of PROT_EXEC.

Although weird, the thought here was that pkey_mprotect() callers are
new and should know about the interactions with PROT_EXEC.  They can
also *get* PROT_EXEC semantics if they want.

The only wart here is if you do:

	mprotect(..., PROT_EXEC); // key 10 is now the PROT_EXEC key
	pkey_mprotect(..., PROT_EXEC, key=3);

I'm not sure what this does.  We should probably ensure that it returns
an error.

> pkey_mprotect(..., -1) or mprotect() will set it to 0-or-PROT_EXEC-pkey.
> 
> Can't shake the feeling that it's somewhat weird, but I guess it's
> flexible at least. So just has to be well documented.

It *is* weird.  But, layering on top of legacy APIs are often weird.  I
would have been open to other sane, but less weird ways to do it a year
ago. :)