pkeys on POWER: Access rights not reset on execve
Michal Suchánek
msuchanek at suse.de
Fri Jun 8 23:49:54 AEST 2018
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.
Thanks
Michal
More information about the Linuxppc-dev
mailing list