Okay. Pretty much what it comes down to is that there is no ideal
solution. Thus, we're trying to explore the potential tradeoffs. The
scenario you describe above will crash horribly for a non-FXSAVE aware
application running on an FXSAVE kernel.
Either way, there has been a long time since, and new bad applications
have obviously emerged, partially "assisted" by our propensity to not
document, and the deep gulf between our kernel and userspace developers.
Let's try another strawman on for size:
- It is clear it is desirable not just for the frame itself but for the
fpstate to be self-describing.
- Thus, let's put a magic cookie in one of the reserved fields at the
end of the FXSAVE region, and make sure it is long enough to be unlikely
to pop up randomly; as well as another magic cookie outside the FXSAVE
region.
- The signal delivery code will write the cookie (or zero, for !XSAVE)
regardless of any crap ptrace might have written into it.
- We will ALSO set bit 0 in uc_flags for RT sigframes as an additional
assurance.
- We will introduce at least a 32-bit field for future use, to be
written unconditionally zero for now. We don't want to have to go
through this particular torture yet again.
- The XSAVE state beyond the FXSAVE region needs to be self-describing.
This may mean adding information not provided by the hardware.
Furthermore, it must be possible for userspace to know the length of the
frame, even if it doesn't understand its detailed contents.
None of this is foolproof on older kernels -- there simply *IS* no
option for older kernels that is 100% guaranteed, thanks to various
assumptions made and design decisions taken over the years. There are a
couple of failure scenarious here:
- XSAVE-aware application running on pre-XSAVE kernel:
Such an application will be aware that the XSAVE information may not
exist, but needs to know (with high probability) that it isn't
present. We have CPUID.OSXSAVE, the uc_flags bit, and the magic
cookie to help here. ptrace can introduce the magic cookie falsely
into the state, but ptrace can introduce all kinds of failures;
either way they would (probablistically) not see the *second*
cookie.
The fact that 64-bit kernels don't clear the unused fields is of
less concern, since 64-bit kernels get the uc_flags field.
- Pre-XSAVE application running on XSAVE kernel with XSAVE enabled:
Here we have the potential for all kinds of corrupt state, including
userspace trying to save away the state and load it later, not
knowing the proper size of it. Worse, some sick person might try to
save and restore state from different hosts, with potential for
all kinds of mayhem.
The saved state, if copied from the original, would contain the first
cookie but not the second cookie.
Again, the use of two cookies here adds some amount of assurance;
but that again amounts to probabilistic failure detection. However,
I personally don't see any way to avoid that scenario at all.
-hpa
--
