pkeys on POWER: Access rights not reset on execve

[Michal Suchánek]

On Fri, 8 Jun 2018 15:51:03 +0200
Florian Weimer <fweimer at redhat.com> wrote:

> 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.
> 

Oh, right. The association of keys to memory is independent of key
allocation. However, to change the key permissions or the memory
association to a key you need to allocate it. And key allocation is
propagated lazily between threads so you do not have to stop the world
to allocate a key. So if default key permissions of an unallocated
key allow access then allocating a key and associating it with memory
makes that memory accessible to threads that are not yet aware of the
fact the key has been allocated which is not desirable.

Sounds sensible.

Thanks

Michal