diff options
Diffstat (limited to 'system/xen/patches/xsa172.patch')
| -rw-r--r-- | system/xen/patches/xsa172.patch | 39 |
1 files changed, 39 insertions, 0 deletions
diff --git a/system/xen/patches/xsa172.patch b/system/xen/patches/xsa172.patch new file mode 100644 index 0000000000000..8b1d01fa8449f --- /dev/null +++ b/system/xen/patches/xsa172.patch @@ -0,0 +1,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 */ |