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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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.

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.

David


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