This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Implement protection key support for POWER
On 05/23/2018 05:25 PM, Carlos O'Donell wrote:
On 05/23/2018 11:14 AM, Florian Weimer wrote:
This still does not address the misc/tst-pkeys failure because there
are kernel bugs.
I'm not entirely sure if the 32-bit AMR mapping is correct because
the kernel allocates keys starting with the MSB position. If in
doubt, we could make this specific to powerpc64.
It's nice to see support for this going in early, and I particularly like
the direction this is going with respect to signal handler support you
are discussing upstream in linux. Involving userspace developers will yield
semantics that make more sense for library and application developers rather
than singular use cases driving the hardware e.g. just the needs of a database.
Is this more of an RFC than PATCH?
No, I believe this is the correct userspace change to enable support for
this feature. The rest has to happen in the kernel.
Regarding this specific patch, what happens when you are not on an ISA3.0
hardware that supports AMR/IAMR/UAMOR registers?
POWER silicon has supported this for ages. The SPR is described in the
2.06 ABI, and probably has been around way longer. binutils GAS still
does not support the mnemonics for AMR access, but the patch does not
use them.
The userspace interface contract is that you have to call pkey_alloc,
and if that succeeds, you know that you an call pkey_set and pkey_get.
pkey_alloc is the only way to get a key number that is usable.
Does tst-pkeys test everything that is required to be tested here?
It does not cover the current fork and execve kernel bugs, no. But it
is kind of hard to write tests now because of the other bugs (the
incorrect UAMOR value, the unfortunate AMR default).
Thanks,
Florian