On 12/13/2017 04:22 PM, Dave Hansen wrote:
On 12/13/2017 07:08 AM, Florian Weimer wrote:
Okay, this model is really quite different from x86. Is there a
good reason for the difference?
Yes, both implementations are simple and take the "natural" behavior.
x86 changes XSAVE-controlled register values on entering a signal, so we
let them be changed (including PKRU). POWER hardware does not do this
to its PKRU-equivalent, so we do not force it to.
Why? Is there a technical reason not have fully-aligned behavior? Can
POWER at least implement the original PKEY_ALLOC_SETSIGNAL semantics
(reset the access rights for certain keys before switching to the signal
handler) in a reasonably efficient manner?
At the very least, if we add a pkey_alloc flag, it should have identical
behavior on both POWER and x86. So it should either reset the access
rights to a fixed value (as posted) or mask out the PKRU reset on x86
(if that's even possible). In the latter case, the POWER would not even
have to change if we keep saying that the default key behavior (without
the flag) is undefined regarding signal handlers.
x86 didn't have to do this for *signals*. But, we kinda went on this
trajectory when we decided to clear/restore FPU state on
entering/exiting signals before XSAVE even existed.
From a userspace perspective, I find this variance rather
disappointing. It's particularly problematic for something like PKRU,
which comes with an entire set of separately configurable keys. I
implemented a per-key knob, but who says that someone else doesn't need
a per-thread or per-signal knob to switch between these incompatible
behaviors?
What can a library assume regarding pkeys behavior if there are
process-global flags that completely alter certain aspects of their
behavior?
FWIW, I do *not* think we have to do this for future XSAVE states. But,
if we do that, we probably need an interface for apps to tell us which
states to save/restore and which state to set upon entering a signal
handler. That's what I was trying to get you to consider instead of
just a one-off hack to fix this for pkeys.
I get that now.
But for pkeys and their access rights, having this configurable at the
PKRU level (as opposed the individual key level) would completely rule
out any use of pkeys in the glibc dynamic linker.
Thanks,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
