Re: [Xen-devel] [PATCHv3 1/3] x86/fpu: improve check for XSAVE* not writing FIP/FDP fields

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.02.16 at 13:18, <david.vrabel@xxxxxxxxxx> wrote:
> On 25/02/16 11:32, Jan Beulich wrote:
>>>>> On 25.02.16 at 11:58, <david.vrabel@xxxxxxxxxx> wrote:
>>> The hardware may not write the FIP/FDP fields with a XSAVE*
>>> instruction.  e.g., with XSAVEOPT/XSAVES if the state hasn't changed
>>> or on AMD CPUs when a floating point exception is not pending.  We
>>> need to identify this case so we can correctly apply the check for
>>> whether to save/restore FCS/FDS.
>>>
>>> By poisoning FIP in the saved state we can check if the hardware
>>> writes to this field.  The poison value is both: a) non-canonical; and
>>> b) random with a vanishingly small probability of matching a value
>>> written by the hardware (1 / (2^63) = 10^-19).
>> 
>> The hardware by itself will always write a canonical value with
>> the 64-bit save variants. The case to consider really is, as said
>> before, that of software storing an arbitrary value there, and
>> for that case I don't think a how ever small probability would
>> make my concerns go away (or else I would have suggested
>> this variation of your previous approach during v2 review).
> 
> Do you not appreciate how unlikely 10^-19 is?
> 
> Assuming a context switch every 1 ms the probability of a error in a
> year is 3e-9.
> 
> The probability of a dinosaur killing asteroid strike in a year is about
> 2e-8.
> 
> I know which one I'd be worried about...

:-)

>>> The poison value is fixed and thus knowable by a guest (or guest
>>> userspace).  This could allow the guest to cause Xen to incorrectly
>>> detect that the field has not been written.  But: a) this requires the
>>> FIP register to be a full 64 bits internally which is not the case for
>>> all current AMD and Intel CPUs; and b) this only allows the guest (or
>>> a guest userspace process) to corrupt its own state (i.e., it cannot
>>> affect the state of another guest or another user space process).
>>>
>>> This results in smaller code with fewer branches and is more
>>> understandable.
>>>
>>> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
>> 
>> Pending confirmation on FIP register width by at least Intel,
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> For Intel CPUs, FIP is 48-bits internally and newer CPUs have FPCSDS and
> thus we will always use the 64-bit save.

Has Intel told you (but not us), or is this just based on experiments
you did, or re-stating what I've found from experimenting?

> For AMD, which only writes FIP and FDP if an exception is pending, if a
> guest wanted to use FIP to store an arbitrary 64-bit value (in some
> future CPU) it would have to manually set an exception as pending.  Its
> seems implausible that any software would actually do this.

All of these uses of FIP/FDP are implausible, yet we're aiming at
correctly mimicking hardware behavior, allowing folks to even do
implausible things that work on bare hardware.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel