[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Xen Security Advisory 62 (CVE-2013-1442) - Information leak on AVX and/or LWP capable
From:       Xen.org security team <security () xen ! org>
Date:       2013-09-25 8:31:11
Message-ID: E1VOkV5-0005Sa-KJ () xenbits ! xen ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2013-1442 / XSA-62
                              version 2

            Information leak on AVX and/or LWP capable CPUs

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

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.

IMPACT
======

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

VULNERABLE SYSTEMS
==================

Xen 4.0 and onwards are vulnerable when run on systems with processors
supporting AVX and/or LWP.  Any kind of guest can exploit the vulnerability.

In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is disabled by
default; therefore systems running these versions are not vulnerable unless
support is explicitly enabled using the "xsave" hypervisor command line option.

Systems using processors supporting neither AVX nor LWP are not vulnerable.

Xen 3.x and earlier are not vulnerable.

MITIGATION
==========

Turning off XSAVE support via the "no-xsave" hypervisor command line option
will avoid the vulnerability.

CREDITS
=======

Jan Beulich discovered this issue.

RESOLUTION
==========

Applying the attached patch resolves this issue.

xsa62.patch                 Xen 4.2.x, 4.3.x, and unstable
xsa62-4.1.patch             Xen 4.1.x

$ sha256sum xsa62*.patch
3cec8ec26552f2142c044422f1bc0f77892e681d789d1f360ecc06e1d714b6bb  xsa62-4.1.patch
364577f317a714099c068eb1ab771643ada99b5067fdd1eb5149fa5db649b856  xsa62.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJSQp1tAAoJEIP+FMlX6CvZvMYIAKe6fyuMdVlP3gJVqAnttQb7
E/TuXwIKBgUFNu34SdkGd6g1l13pfSeiovDD56SqNj5kwCD0rb6+LgHu/uqVsxSn
w+JtPGFXQpAfNzEcDPqYP9ArJIp63ogC9CLwk9KcDoy0FnxpHFD3Ke5C62G83DAJ
qhjEpknTQCwjXBG6fYXjYKhFR8kzkWHGRpECE3EwlLo1gWxQj8/p/TopY8kzmA5m
ssDuM/XzBHjI+7NwiB5oNuZfS8Om+UVQUilv+bjarh9zJy55FGSL1gJzdcXGhFx5
sXw/PcciIAcCC8k8f2+tYY1eN9Orthw81YMh9Q/n6JC4RMgBYK3tkZ9AsOR7H9s=
=Qbk6
-----END PGP SIGNATURE-----

["xsa62-4.1.patch" (application/octet-stream)]

x86/xsave: initialize unused register state when restoring for guest

In order to avoid leaking register contents from the prior use of the
registers restored through xrstor due to a guest enabling certain xcr0
bits late (particularly after the context restor in question), force
restoring of all known registers (the ones that never got saved would
be forced to their init state).

This is CVE-2013-1442 / XSA-62.

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
@@ -103,9 +103,9 @@ void setup_fpu(struct vcpu *v)
     {
         /*
          * XCR0 normally represents what guest OS set. In case of Xen itself, 
-         * we set all supported feature mask before doing save/restore.
+         * we set all supported feature mask before restoring.
          */
-        set_xcr0(v->arch.xcr0_accum);
+        set_xcr0(xfeature_mask);
         xrstor(v);
         set_xcr0(v->arch.xcr0);
     }
@@ -149,7 +149,7 @@ void save_init_fpu(struct vcpu *v)
     if ( xsave_enabled(v) )
     {
         /* XCR0 normally represents what guest OS set. In case of Xen itself,
-         * we set all accumulated feature mask before doing save/restore.
+         * we set all accumulated feature mask before saving.
          */
         set_xcr0(v->arch.xcr0_accum);
         if ( cpu_has_xsaveopt )

["xsa62.patch" (application/octet-stream)]

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.

This is CVE-2013-1442 / XSA-62.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

--- 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;
 }
 


[prev in list] [next in list] [prev in thread] [next in thread]