Re: pkeys on POWER: Default AMR, UAMOR values

On Fri, May 18, 2018 at 10:45 AM Ram Pai [off-list ref] wrote:

On Fri, May 18, 2018 at 03:17:14PM +0200, Florian Weimer wrote:

quoted

I'm working on adding POWER pkeys support to glibc.  The coding work
is done, but I'm faced with some test suite failures.

Unlike the default x86 configuration, on POWER, existing threads
have full access to newly allocated keys.

Or, more precisely, in this scenario:

* Thread A launches thread B
* Thread B waits
* Thread A allocations a protection key with pkey_alloc
* Thread A applies the key to a page
* Thread A signals thread B
* Thread B starts to run and accesses the page

Then at the end, the access will be granted.

I hope it's not too late to change this to denied access.

Furthermore, I think the UAMOR value is wrong as well because it
prevents thread B at the end to set the AMR register.  In
particular, if I do this

* =E2=80=A6 (as before)
* Thread A signals thread B
* Thread B sets the access rights for the key to PKEY_DISABLE_ACCESS
* Thread B reads the current access rights for the key

then it still gets 0 (all access permitted) because the original
UAMOR value inherited from thread A prior to the key allocation
masks out the access right update for the newly allocated key.

Florian, is the behavior on x86 any different? A key allocated in the
context off one thread is not meaningful in the context of any other
thread.

The difference is that x86 starts out with deny-all instead of allow-all.
The POWER semantics make it very hard for a multithreaded program to
meaningfully use protection keys to prevent accidental access to important
memory.