pkeys on POWER: Access rights not reset on execve

[Florian Weimer]

On 06/08/2018 03:49 PM, Michal Suchánek wrote:
> On Fri, 8 Jun 2018 14:57:06 +0200
> Florian Weimer <fweimer at redhat.com> wrote:
> 
>> On 06/08/2018 02:54 PM, Michal Suchánek wrote:
>>> On Fri, 8 Jun 2018 12:44:53 +0200
>>> Florian Weimer <fweimer at redhat.com> wrote:
>>>    
>>>> On 06/08/2018 12:15 PM, Michal Suchánek wrote:
>>>>> On Fri, 8 Jun 2018 07:53:51 +0200
>>>>> Florian Weimer <fweimer at redhat.com> wrote:
>>>>>       
>>>>>> On 06/08/2018 04:34 AM, Ram Pai wrote:
>>>>>>>>
>>>>>>>> So the remaining question at this point is whether the Intel
>>>>>>>> behavior (default-deny instead of default-allow) is
>>>>>>>> preferable.
>>>>>>>
>>>>>>> Florian, remind me what behavior needs to fixed?
>>>>>>
>>>>>> See the other thread.  The Intel register equivalent to the AMR
>>>>>> by default disallows access to yet-unallocated keys, so that
>>>>>> threads which are created before key allocation do not magically
>>>>>> gain access to a key allocated by another thread.
>>>>>>      
>>>>>
>>>>> That does not make any sense. The threads share the address space
>>>>> so they should also share the keys.
>>>>>
>>>>> Or in other words the keys are supposed to be acceleration of
>>>>> mprotect() so if mprotect() magically gives access to threads that
>>>>> did not call it so should pkey functions. If they cannot do that
>>>>> then they fail the primary purpose.
>>>>
>>>> That's not how protection keys work.  The access rights are
>>>> thread-specific, so that you can change them locally, without
>>>> synchronization and expensive inter-node communication.
>>>>   
>>>
>>> And the association of a key with part of the address space is
>>> thread-local as well?
>>
>> No, that part is still per-process.
> 
> So as said above it does not make sense to make keys per-thread.

The keys are still global, but the access rights are per-thread and have 
to be for reliability reasons.

Thanks,
Florian