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

ref #2044
ref #2049
ref #2054
fixes #2045
fixes #2050
fixes #2055
(cherry picked from commit f6e99451d47fbe7cdb852f48dd11006808db52ae)

4 files changed, 140 insertions, 1 deletions

diff --git a/main/xen/APKBUILD b/main/xen/APKBUILD
index 0a972ff837..c052f76f4c 100644
--- a/main/xen/APKBUILD
+++ b/main/xen/APKBUILD
@@ -3,7 +3,7 @@
 # Maintainer: William Pitcock <nenolod@dereferenced.org>
 pkgname=xen
 pkgver=4.2.2
-pkgrel=0
+pkgrel=2
 pkgdesc="Xen hypervisor"
 url="http://www.xen.org/"
 arch="x86 x86_64"
@@ -24,6 +24,9 @@ source="http://bits.xensource.com/oss-xen/release/$pkgver/$pkgname-$pkgver.tar.g
         xsa41b.patch
         xsa41c.patch
         xsa48-4.2.patch
+        xsa52-4.2-unstable.patch
+        xsa53-4.2.patch
+        xsa54.patch
         xsa56.patch
 
         fix-pod2man-choking.patch
@@ -149,6 +152,9 @@ md5sums="f7362b19401a47826f2d8fd603a1782a  xen-4.2.2.tar.gz
 ed7d0399c6ca6aeee479da5d8f807fe0  xsa41b.patch
 2f3dd7bdc59d104370066d6582725575  xsa41c.patch
 b3e3a57d189a4f86c9766eaf3b5207f4  xsa48-4.2.patch
+83a9cdd035bcd18bf035434a1ba08c38  xsa52-4.2-unstable.patch
+03a1a4ebc470ee7e638e04db2701a4f7  xsa53-4.2.patch
+a8393d1ec6b886ea72ffe624a04ee10a  xsa54.patch
 e70b9128ffc2175cea314a533a7d8457  xsa56.patch
 c1d1a415415b0192e5dae9032962bf61  fix-pod2man-choking.patch
 95d8af17bf844d41a015ff32aae51ba1  xenstored.initd
@@ -171,6 +177,9 @@ a0c225d716d343fe041b63e3940900c5b3573ed3bcfc5b7c2d52ea2861c3fc28  docs-Fix-gener
 896a07f57310c9bea9bc2a305166cf796282c381cb7839be49105b1726a860b5  xsa41b.patch
 683dd96a0a8899f794070c8c09643dfeeb39f92da531955cba961b45f6075914  xsa41c.patch
 dc23077028584e71a08dd0dc9e81552c76744a5ce9d39df5958a95ae9cf3107b  xsa48-4.2.patch
+5b8582185bf90386729e81db1f7780c69a891b074a87d9a619a90d6f639bea13  xsa52-4.2-unstable.patch
+785f7612bd229f7501f4e98e4760f307d90c64305ee14707d262b77f05fa683d  xsa53-4.2.patch
+5d94946b3c9cba52aae2bffd4b0ebb11d09181650b5322a3c85170674a05f6b7  xsa54.patch
 a691c5f5332a42c0d38ddb4dc037eb902f01ba31033b64c47d02909a8de0257d  xsa56.patch
 b4e7d43364a06b2cb04527db3e9567524bc489fef475709fd8493ebf1e62406d  fix-pod2man-choking.patch
 81d335946c81311c86e2f2112b773a568a5a530c0db9802b2fe559e71bb8b381  xenstored.initd
@@ -193,6 +202,9 @@ sha512sums="4943b18016ed8c2b194a3b55e6655b3b734b39ffb8cb7ee0a0580f2f4460a1d0e92e
 bda9105793f2327e1317991762120d0668af0e964076b18c9fdbfd509984b2e88d85df95702c46b2e00d5350e8113f6aa7b34b19064d19abbeb4d43f0c431d38  xsa41b.patch
 36b60478660ff7748328f5ab9adff13286eee1a1bad06e42fdf7e6aafe105103988525725aacd660cf5b2a184a9e2d6b3818655203c1fa07e07dcebdf23f35d9  xsa41c.patch
 31dd8c62d41cc0a01a79d9b24a5b793f5e2058230808d9c5364c6ff3477ab02f3258f1bbd761d97dc1b97ee120b41524b999eaac77f33b606496fc324b5fa2e4  xsa48-4.2.patch
+b64a965fab8534958e453c493211ed3a6555aafb90d18f6d56a45b41d3086a0029aee85b6b6eb93b0d861d5fdc0ef10fc32e9b4f83593b37c43922d838085dd8  xsa52-4.2-unstable.patch
+9b08924e563e79d2b308c1521da520c0579b334b61ac99a5593eabdb96dbda2da898b542cc47bda6d663c68343216d9d29c04853b6d1b6ecdde964b0cbb3f7ab  xsa53-4.2.patch
+c9010be637d4f96ef03c880e1ef28228f762c5980108380a105bd190b631a882c8dff81e9421246d88d597e72f69ad1a8c672be6ddd06936acfcacd4575a2650  xsa54.patch
 26a1c2cc92ddd4c1ab6712b0e41a0135d0e76a7fe3a14b651fb0235e352e5a24077414371acccb93058b7ce4d882b667386811170ba74570c53165837bcd983d  xsa56.patch
 ffb1113fcec0853b690c177655c7d1136388efdebf0d7f625b80481b98eadd3e9ef461442ced53e11acf0e347800a2b0a41e18b05065b5d04bffdd8a4e127cec  fix-pod2man-choking.patch
 792b062e8a16a2efd3cb4662d379d1500527f2a7ca9228d7831c2bd34f3b9141df949153ea05463a7758c3e3dd9a4182492ad5505fa38e298ecf8c99db77b4ee  xenstored.initd
diff --git a/main/xen/xsa52-4.2-unstable.patch b/main/xen/xsa52-4.2-unstable.patch
new file mode 100644
index 0000000000..14db8a8a7f
--- /dev/null
+++ b/main/xen/xsa52-4.2-unstable.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/xstate.c
++++ b/xen/arch/x86/xstate.c
+@@ -78,6 +78,21 @@ void xrstor(struct vcpu *v, uint64_t mas
+ 
+     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 ( (mask & 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.2.patch b/main/xen/xsa53-4.2.patch
new file mode 100644
index 0000000000..eb8e79bed2
--- /dev/null
+++ b/main/xen/xsa53-4.2.patch
@@ -0,0 +1,57 @@
+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
+@@ -53,7 +53,7 @@ static inline void fpu_fxrstor(struct vc
+     /*
+      * 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.
+      */
+     asm volatile (
+ #ifdef __i386__
+--- a/xen/arch/x86/xstate.c
++++ b/xen/arch/x86/xstate.c
+@@ -93,10 +93,25 @@ void xrstor(struct vcpu *v, uint64_t mas
+                        "fildl %0"          /* load to clear state */
+                        : : "m" (ptr->fpu_sse) );
+ 
+-    asm volatile (
+-        ".byte " REX_PREFIX "0x0f,0xae,0x2f"
+-        :
+-        : "m" (*ptr), "a" (lmask), "d" (hmask), "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 %5,%%ecx       \n"
++                   "   xor %1,%1          \n"
++                   "   rep stosb          \n"
++                   "   lea %2,%0          \n"
++                   "   mov %3,%1          \n"
++                   "   jmp 1b             \n"
++                   ".previous             \n"
++                   _ASM_EXTABLE(1b, 2b)
++                   : "+&D" (ptr), "+&a" (lmask)
++                   : "m" (*ptr), "g" (lmask), "d" (hmask),
++                     "m" (xsave_cntxt_size)
++                   : "ecx" );
+ }
+ 
+ bool_t xsave_enabled(const struct vcpu *v)
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);