aboutsummaryrefslogtreecommitdiffstats
path: root/tools/lib/sys_string.h
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2013-06-04 09:33:29 +0200
committerJan Beulich <jbeulich@suse.com>2013-06-04 09:33:29 +0200
commit16b0db2eeef6491fee4277b030c84678b1579863 (patch)
tree41240d3dff635ca0ae26c481cc679ef8bdb46b08 /tools/lib/sys_string.h
parent34e2c78baa7eff6369595adc7e51e70a4a0c8727 (diff)
downloadxen-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