On 05/18/2018 07:44 PM, Ram Pai wrote:
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."
I reported two separate issues (actually three, but the execve bug is in a separate issue). The default, and the write restrictions.
The default is just a difference to x86 (however, x86 can be booted with init_pkru=0 and behaves the same way, but we're probably going to remove that).
The POWER implementation has the additional wrinkle that threads launched early, before key allocation, can never change access rights because they inherited not just the access rights, but also the access rights access mask. This is different from x86, where all threads can freely update access rights, and contradicts the behavior in the manpage which says that “each child thread can perform its own initialization of protection key rights”. It can't do that if it is launched before key allocation, which is not the right behavior IMO.
Thanks, Florian
