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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 25/02/16 12:49, David Vrabel wrote:
> 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.

No OS is plausibly going to hide non-IP information in FIP.

If some theoretical OS does do something like that, there is always the
override available.

~Andrew

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