diff options
| author | Jan Beulich <jbeulich@suse.com> | 2013-06-04 09:33:29 +0200 |
|---|---|---|
| committer | Jan Beulich <jbeulich@suse.com> | 2013-06-04 09:33:29 +0200 |
| commit | 16b0db2eeef6491fee4277b030c84678b1579863 (patch) | |
| tree | 41240d3dff635ca0ae26c481cc679ef8bdb46b08 /tools/lib/sys_string.h | |
| parent | 34e2c78baa7eff6369595adc7e51e70a4a0c8727 (diff) | |
| download | xen-16b0db2eeef6491fee4277b030c84678b1579863.tar.gz xen-16b0db2eeef6491fee4277b030c84678b1579863.tar.bz2 xen-16b0db2eeef6491fee4277b030c84678b1579863.zip | |
x86/xsave: fix information leak on AMD CPUs
Just like for FXSAVE/FXRSTOR, XSAVE/XRSTOR also don't save/restore the
last instruction and operand pointers as well as the last opcode if
there's no pending unmasked exception (see CVE-2006-1056 and commit
9747:4d667a139318).
While the FXSR solution sits in the save path, I prefer to have this in
the restore path because there the handling is simpler (namely in the
context of the pending changes to properly save the selector values for
32-bit guest code).
Also this is using FFREE instead of EMMS, as it doesn't seem unlikely
that in the future we may see CPUs with x87 and SSE/AVX but no MMX
support. The goal here anyway is just to avoid an FPU stack overflow.
I would have preferred to use FFREEP instead of FFREE (freeing two
stack slots at once), but AMD doesn't document that instruction.
This is CVE-2013-2076 / XSA-52.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
master commit: 8dcf9f0113454f233089e8e5bb3970d891928410
master date: 2013-06-04 09:26:54 +0200
Diffstat (limited to 'tools/lib/sys_string.h')
0 files changed, 0 insertions, 0 deletions
