pkey_alloc/pkey_free semantics

pkey_alloc/pkey_free semantics

[Florian Weimer]

I'm implementing the memory protection key interfaces for glibc and 
noticed that the pkey_alloc manpage in particular is a bit removed from 
reality.

Here's what I found:

The flags argument is reserved and currently must be zero.

The access_rights argument instructs the kernel to set the access rights 
for the new key for the current thread only (!).  It's a bitmask with 
bits PKEY_DISABLE_ACCESS and PKEY_DISABLE_WRITE.

So in essence, both arguments are not needed right now because the 
access rights of the current thread for the new key could easily be 
changed in user space.

To repeat, pkey_alloc affects the access rights of the current thread. 
Other threads retain their existing access rights.  The default rights 
for the process apparently can be set with the init_pkru parameter on 
recent kernels (I have not tried that).

The manpage mentions only the key leak related to pkey_mprotect 
(pkey_free while a page still is still associated with that key).  There 
is another one which affects a pkey_alloc/pthread_create/pkey_free 
sequence, where any created threads retain their access rights.  I 
raised this issue of key reuse in a recent thread (MPK: pkey_free and 
key reuse), so perhaps there will be a way

Anyway, the important manpage fix for now would be to fix the 
description of the flags and access_rights parameters.

Thanks,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pkey_alloc/pkey_free semantics

[Florian Weimer]

On 11/05/2017 12:39 PM, Florian Weimer wrote:

> Anyway, the important manpage fix for now would be to fix the 
> description of the flags and access_rights parameters.

One more thing:

The pkey_alloc system call returns EINVAL, not ENOSPC, if the system 
does not support memory protection keys (at least in the Intel 
implementation, have not checked POWER).

Thanks,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html