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. Since thread B was created prior to the creation of the key, and the key was created in the context of thread A, thread B neither inherits the key nor its permissions. Atleast that is how the semantics are supposed to work as per the man page. man 7 pkey " Applications using threads and protection keys should be especially careful. Threads inherit the protection key rights of the parent at the time of the clone(2), system call. Applications should either ensure that their own permissions are appropriate for child threads at the time when clone(2) is called, or ensure that each child thread can perform its own initialization of protection key rights." RP
