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

[David Vrabel <david.vrabel@citrix.com>]

On 25/02/16 12:27, Jan Beulich wrote:
>>>> On 25.02.16 at 13:18, <david.vrabel@citrix.com> wrote:
>> On 25/02/16 11:32, Jan Beulich wrote:
>>>>>> On 25.02.16 at 11:58, <david.vrabel@citrix.com> wrote:
>>>> 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@citrix.com>
>>>
>>> Pending confirmation on FIP register width by at least Intel,
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>
>> 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?

I'm just restating things already mentioned in the various threads.

>> 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.

I think:

a) On hardware with FPCSDS, we always do a 64-bit save/restore and thus
always match the hardware behaviour.

b) On hardware without FPCSDS we /cannot/ match the hardware behaviour.
 We must have some sort of heuristic to cover the common use cases.  The
existing heuristic is /already/ inadequate since Driver Verifier
confuses it. So IMO, making the heuristic a teeny, tiny bit less precise
doesn't matter.

c) For the uncommon use cases, there is always HVM_PARAM_X87_FIP_WIDTH
to force a particular behaviour.

David

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