pkeys on POWER: Default AMR, UAMOR values
Ram Pai
linuxram at us.ibm.com
Sat May 19 10:52:19 AEST 2018
On Fri, May 18, 2018 at 11:13:30PM +0200, Florian Weimer wrote:
> On 05/18/2018 09:39 PM, Andy Lutomirski wrote:
> >The difference is that x86 starts out with deny-all instead of allow-all.
Ah!. this explains the discrepency. But still does not explain one
thing.. see below.
> >The POWER semantics make it very hard for a multithreaded program to
> >meaningfully use protection keys to prevent accidental access to important
> >memory.
>
> And you can change access rights for unallocated keys (unallocated
> at thread start time, allocated later) on x86. I have extended the
> misc/tst-pkeys test to verify that, and it passes on x86, but not on
> POWER, where the access rights are stuck.
This is something I do not understand. How can a thread change permissions
on a key, that is not even allocated in the first place. Do you consider a key
allocated in some other thread's context, as allocated in this threads
context? If not, does that mean -- On x86, you can activate a key just
by changing its permission?
RP
More information about the Linuxppc-dev
mailing list