On 11/22/2017 05:32 PM, Dave Hansen wrote:

On 11/22/2017 08:21 AM, Florian Weimer wrote:

quoted

On 11/22/2017 05:10 PM, Dave Hansen wrote:

quoted

On 11/22/2017 04:15 AM, Florian Weimer wrote:

quoted

On 11/22/2017 09:18 AM, Vlastimil Babka wrote:

quoted

And, was the pkey == -1 internal wiring supposed to be exposed to the
pkey_mprotect() signal, or should there have been a pre-check returning
EINVAL in SYSCALL_DEFINE4(pkey_mprotect), before calling
do_mprotect_pkey())? I assume it's too late to change it now anyway (or
not?), so should we also document it?

I think the -1 case to the set the default key is useful because it
allows you to use a key value of -1 to mean “MPK is not supported”, and
still call pkey_mprotect.

The behavior to not allow 0 to be set was unintentional and is a bug.
We should fix that.

On the other hand, x86-64 has no single default protection key due to
the PROT_EXEC emulation.

No, the default is clearly 0 and documented to be so.  The PROT_EXEC
emulation one should be inaccessible in all the APIs so does not even
show up as *being* a key in the API.  The fact that it's implemented
with pkeys should be pretty immaterial other than the fact that you
can't touch the high bits in PKRU.

So, just to be sure, if we call pkey_mprotect() with 0, will it blindly
set 0, or the result of arch_override_mprotect_pkey() (thus equivalent
to call with -1) ? I assume the latter?