[PATCH] Linux: Implement interfaces for memory protection keys

[Florian Weimer]

On 12/05/2017 03:06 PM, Adhemerval Zanella wrote:

>>>> +@deftypefun int pkey_free (int @var{key})
>>>> +@standards{Linux, sys/mman.h}
>>>> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
>>>> +Deallocate the protection key, so that it can be reused by
>>>> +@code{pkey_alloc}.
>>>> +
>>>> +Calling this function does not change the access rights of the freed
>>>> +protection key.  The calling thread and other threads may retain access
>>>> +to it, even if it is subsequently allocated again.  For this reason, it
>>>> +is not recommended to call the @code{pkey_free} function.
>>>
>>> I presume you are referring to your 'MPK: pkey_free and key reuse' discussion,
>>> but should we add a note that 'pkey_free' should be as long as the application
>>> make sure to munmap the pages associated with the key meant to free first?
>>
>> No, it's also relevant that threads retain access when the key is reused.
> 
> My understanding is if we pkey_alloc -> mprotect -> munmap -> pkey_free,
> it should not create any other side effects even for key reuse.  Or am
> I missing something here?

If there's a pthread_create call between pkey_alloc and pkey_free, and 
the thread is still running after the pkey_free, then that thread will 
retain the access rights of the original thread at the time 
pthread_create was called.

> LGTM and we may extend the pkey_free documentation later if it were the case.

Thanks.

> As a side note what are you ideas regarding using pkey on glibc (and could you
> extend the idea of the GOT protection as well)?

Nick Clifton wrote a binutils patch for me which isolates the GOT on a 
dedicated page and adds a new DT_* entry with the GOT size.  We can then 
allocate a protection key and apply it to all GOTs in the process. 
Default access rights for all threads is PKEY_DISABLE_WRITE.  _dl_fixup 
will temporarily disable that to retain write access to the GOT before 
storing the pointer.

This will need a kernel patch to allow us to specify that we want 
PKEY_DISABLE_WRITE for the key in signal handlers, not 
PKEY_DISABLE_ACCESS (as it is the case for some configurations). 
Without that, lazy binding from signal handlers will be broken.  We can 
implement this with a pkey_alloc flag, so the existing APIs are fine.

Florian