Information leak on AVX and/or LWP capable CPUs

When a guest increases the set of extended state components for a vCPU saved/restored via XSAVE/XRSTOR (to date this can only be the upper halves of YMM registers, or AMD’s LWP state) after already having touched other extended registers restored via XRSTOR (e.g. floating point or XMM ones) during its current scheduled CPU quantum, the hypervisor would make those registers accessible without discarding the values an earlier scheduled vCPU may have left in them.

logic error (not clear previous states)



x86/xsave: initialize extended register state when guests enable it

Till now, when setting previously unset bits in XCR0 we wouldn’t touch the active register state, thus leaving in the newly enabled registers whatever a prior user of it left there, i.e. potentially leaking information between guests.

--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -307,6 +307,7 @@ int validate_xstate(u64 xcr0, u64 xcr0_a
 int handle_xsetbv(u32 index, u64 new_bv)
     struct vcpu *curr = current;
+    u64 mask;
     if ( index != XCR_XFEATURE_ENABLED_MASK )
         return -EOPNOTSUPP;
@@ -320,9 +321,23 @@ int handle_xsetbv(u32 index, u64 new_bv)
     if ( !set_xcr0(new_bv) )
         return -EFAULT;
+    mask = new_bv & ~curr->arch.xcr0_accum;
     curr->arch.xcr0 = new_bv;
     curr->arch.xcr0_accum |= new_bv;
+    mask &= curr->fpu_dirtied ? ~XSTATE_FP_SSE : XSTATE_NONLAZY;
+    if ( mask )
+    {
+        unsigned long cr0 = read_cr0();
+        clts();
+        if ( curr->fpu_dirtied )
+            asm ( "stmxcsr %0" : "=m" (curr->arch.xsave_area->fpu_sse.mxcsr) );
+        xrstor(curr, mask);
+        if ( cr0 & X86_CR0_TS )
+            write_cr0(cr0);
+    }
     return 0;


A malicious domain may be able to leverage this to obtain sensitive information such as cryptographic keys from another domain.

information leak