On Fri, May 18, 2018 at 10:45 AM Ram Pai <linuxram@xxxxxxxxxx> wrote: > On Fri, May 18, 2018 at 03:17:14PM +0200, Florian Weimer wrote: > > 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 > > > > * … (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.