Commit 9da25b87 authored by Natanael Copa's avatar Natanael Copa

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
parent 563e2f3d
......@@ -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
......
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"
:
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 )
{
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);
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment