On Fri, 8 Jun 2018 14:57:06 +0200 Florian Weimer <fwei...@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 <fwei...@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 <fwei...@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
