main/xen: security fixes (CVE-2013-2076,CVE-2013-2077,CVE-2013-2078)

ref #2044
ref #2049
ref #2054
fixes #2048
fixes #2053
fixes #2058

4 files changed, 132 insertions, 1 deletions

diff --git a/main/xen/APKBUILD b/main/xen/APKBUILD
index f29c4d763e..c3fd941717 100644
--- a/main/xen/APKBUILD
+++ b/main/xen/APKBUILD
@@ -2,7 +2,7 @@
 # Maintainer: William Pitcock <nenolod@dereferenced.org>
 pkgname=xen
 pkgver=4.1.4
-pkgrel=3
+pkgrel=4
 pkgdesc="Xen hypervisor"
 url="http://www.xen.org/"
 arch="x86 x86_64"
@@ -23,6 +23,9 @@ source="http://bits.xensource.com/oss-xen/release/$pkgver/$pkgname-$pkgver.tar.g
 	busybox-sed.patch
 	xsa33-4.1.patch
 	xsa41.patch
+	xsa52-4.1.patch
+	xsa53-4.1.patch
+	xsa54.patch
 	xsa56.patch
 
 	xencommons.initd
@@ -101,6 +104,9 @@ fa06495a175571f4aa3b6cb88937953e  librt.patch
 1bea3543ddc712330527b62fd9ff6520  busybox-sed.patch
 25ba4efc5eee29daa12855fbadce84f8  xsa33-4.1.patch
 ce56f00762139cd611dfc3332b7571cf  xsa41.patch
+db1e5a92547c8c8ed2e1872efed99ab0  xsa52-4.1.patch
+e11ae888997d11fcb91b431ebf609d4e  xsa53-4.1.patch
+a8393d1ec6b886ea72ffe624a04ee10a  xsa54.patch
 e70b9128ffc2175cea314a533a7d8457  xsa56.patch
 0b62c1fbe2699a32e745724fd301db5b  xencommons.initd
 5ee6a16ec70dfbcd4944ded71b393fa2  xend.initd
diff --git a/main/xen/xsa52-4.1.patch b/main/xen/xsa52-4.1.patch
new file mode 100644
index 0000000000..39336303bc
--- /dev/null
+++ b/main/xen/xsa52-4.1.patch
@@ -0,0 +1,46 @@
+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>
+
+--- a/xen/arch/x86/i387.c
++++ b/xen/arch/x86/i387.c
+@@ -44,6 +44,21 @@ static void xrstor(struct vcpu *v)
+ {
+     struct xsave_struct *ptr = v->arch.xsave_area;
+ 
++    /*
++     * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
++     * is pending. Clear the x87 state here by setting it to fixed
++     * values. The hypervisor data segment can be sometimes 0 and
++     * 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 ( (ptr->xsave_hdr.xstate_bv & XSTATE_FP) &&
++         !(ptr->fpu_sse.fsw & 0x0080) &&
++         boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
++        asm volatile ( "fnclex\n\t"        /* clear exceptions */
++                       "ffree %%st(7)\n\t" /* clear stack tag */
++                       "fildl %0"          /* load to clear state */
++                       : : "m" (ptr->fpu_sse) );
++
+     asm volatile (
+         ".byte " REX_PREFIX "0x0f,0xae,0x2f"
+         :
diff --git a/main/xen/xsa53-4.1.patch b/main/xen/xsa53-4.1.patch
new file mode 100644
index 0000000000..522bf13b24
--- /dev/null
+++ b/main/xen/xsa53-4.1.patch
@@ -0,0 +1,55 @@
+x86/xsave: recover from faults on XRSTOR
+
+Just like FXRSTOR, XRSTOR can raise #GP if bad content is being passed
+to it in the memory block (i.e. aspects not under the control of the
+hypervisor, other than e.g. proper alignment of the block).
+
+Also correct the comment explaining why FXRSTOR needs exception
+recovery code to not wrongly state that this can only be a result of
+the control tools passing a bad image.
+
+This is CVE-2013-2077 / XSA-53.
+
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+
+--- a/xen/arch/x86/i387.c
++++ b/xen/arch/x86/i387.c
+@@ -59,10 +59,25 @@ static void xrstor(struct vcpu *v)
+                        "fildl %0"          /* load to clear state */
+                        : : "m" (ptr->fpu_sse) );
+ 
+-    asm volatile (
+-        ".byte " REX_PREFIX "0x0f,0xae,0x2f"
+-        :
+-        : "m" (*ptr), "a" (-1), "d" (-1), "D"(ptr) );
++    /*
++     * XRSTOR can fault if passed a corrupted data block. We handle this
++     * possibility, which may occur if the block was passed to us by control
++     * tools or through VCPUOP_initialise, by silently clearing the block.
++     */
++    asm volatile ( "1: .byte " REX_PREFIX "0x0f,0xae,0x2f\n"
++                   ".section .fixup,\"ax\"\n"
++                   "2: mov %4,%%ecx       \n"
++                   "   xor %1,%1          \n"
++                   "   rep stosb          \n"
++                   "   lea %3,%0          \n"
++                   "   dec %1             \n"
++                   "   jmp 1b             \n"
++                   ".previous             \n"
++                   _ASM_EXTABLE(1b, 2b)
++                   : "+&D" (ptr)
++                   : "a" (-1), "d" (-1), "m" (*ptr),
++                     "m" (xsave_cntxt_size)
++                   : "ecx" );
+ }
+ 
+ static void load_mxcsr(unsigned long val)
+@@ -196,7 +211,7 @@ static void restore_fpu(struct vcpu *v)
+     /*
+      * FXRSTOR can fault if passed a corrupted data block. We handle this
+      * possibility, which may occur if the block was passed to us by control
+-     * tools, by silently clearing the block.
++     * tools or through VCPUOP_initialise, by silently clearing the block.
+      */
+     if ( cpu_has_fxsr )
+     {
diff --git a/main/xen/xsa54.patch b/main/xen/xsa54.patch
new file mode 100644
index 0000000000..83c8993d6a
--- /dev/null
+++ b/main/xen/xsa54.patch
@@ -0,0 +1,24 @@
+x86/xsave: properly check guest input to XSETBV
+
+Other than the HVM emulation path, the PV case so far failed to check
+that YMM state requires SSE state to be enabled, allowing for a #GP to
+occur upon passing the inputs to XSETBV inside the hypervisor.
+
+This is CVE-2013-2078 / XSA-54.
+
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+
+--- a/xen/arch/x86/traps.c
++++ b/xen/arch/x86/traps.c
+@@ -2205,6 +2205,11 @@ static int emulate_privileged_op(struct 
+                     if ( !(new_xfeature & XSTATE_FP) || (new_xfeature & ~xfeature_mask) )
+                         goto fail;
+ 
++                    /* YMM state takes SSE state as prerequisite. */
++                    if ( (xfeature_mask & new_xfeature & XSTATE_YMM) &&
++                         !(new_xfeature & XSTATE_SSE) )
++                        goto fail;
++
+                     v->arch.xcr0 = new_xfeature;
+                     v->arch.xcr0_accum |= new_xfeature;
+                     set_xcr0(new_xfeature);