>>> On 25.02.16 at 11:58, <david.vra...@citrix.com> 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). > 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.vra...@citrix.com> Pending confirmation on FIP register width by at least Intel, Reviewed-by: Jan Beulich <jbeul...@suse.com> Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
