blob: 8b1d01fa8449fe206ef738c7691c910596b684bc (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
x86: fix information leak on AMD CPUs
The fix for XSA-52 was wrong, and so was the change synchronizing that
new behavior to the FXRSTOR logic: AMD's manuals explictly state that
writes to the ES bit are ignored, and it instead gets calculated from
the exception and mask bits (it gets set whenever there is an unmasked
exception, and cleared otherwise). Hence we need to follow that model
in our workaround.
This is XSA-172.
The first hunk (xen/arch/x86/i387.c:fpu_fxrstor) is CVE-2016-3159.
The second hunk (xen/arch/x86/xstate.c:xrstor) is CVE-2016-3158.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -49,7 +49,7 @@ static inline void fpu_fxrstor(struct vc
* sometimes new user value. Both should be ok. Use the FPU saved
* data block as a safe address because it should be in L1.
*/
- if ( !(fpu_ctxt->fsw & 0x0080) &&
+ if ( !(fpu_ctxt->fsw & ~fpu_ctxt->fcw & 0x003f) &&
boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
{
asm volatile ( "fnclex\n\t"
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -344,7 +344,7 @@ void xrstor(struct vcpu *v, uint64_t mas
* data block as a safe address because it should be in L1.
*/
if ( (mask & ptr->xsave_hdr.xstate_bv & XSTATE_FP) &&
- !(ptr->fpu_sse.fsw & 0x0080) &&
+ !(ptr->fpu_sse.fsw & ~ptr->fpu_sse.fcw & 0x003f) &&
boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
asm volatile ( "fnclex\n\t" /* clear exceptions */
"ffree %%st(7)\n\t" /* clear stack tag */
|
