Thread (31 messages) flat view 31 messages, 4 authors, 2018-06-12

Re: pkeys on POWER: Access rights not reset on execve

From: Florian Weimer <hidden>
Date: 2018-06-08 13:51:07
Also in: linux-mm

On 06/08/2018 03:49 PM, Michal Suchánek wrote:
On Fri, 8 Jun 2018 14:57:06 +0200
Florian Weimer [off-list ref] wrote:
quoted
On 06/08/2018 02:54 PM, Michal Suchánek wrote:
quoted
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer [off-list ref] wrote:
   
quoted
On 06/08/2018 12:15 PM, Michal Suchánek wrote:
quoted
On Fri, 8 Jun 2018 07:53:51 +0200
Florian Weimer [off-list ref] wrote:
      
quoted
On 06/08/2018 04:34 AM, Ram Pai wrote:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help