* Xen Security Advisory 202 (CVE-2016-10024) - x86 PV guests may be able to mask interrupts
@ 2016-12-21 12:01 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2016-12-21 12:01 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2016-10024 / XSA-202
version 3
x86 PV guests may be able to mask interrupts
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
Certain PV guest kernel operations (page table writes in particular)
need emulation, and use Xen's general x86 instruction emulator. This
allows a malicious guest kernel which asynchronously modifies its
instruction stream to effect the clearing of EFLAGS.IF from the state
used to return to guest context.
IMPACT
======
A malicious guest kernel administrator can cause a host hang or
crash, resulting in a Denial of Service.
VULNERABLE SYSTEMS
==================
All Xen versions are vulnerable.
Only x86 PV guests can exploit the vulnerability.
Neither ARM guests nor x86 HVM guests can exploit the vulnerability.
MITIGATION
==========
Running only HVM guests will avoid the vulnerability.
For PV guests the vulnerability can be avoided if the guest kernel is
controlled by the host rather than guest administrator, provided that
further steps are taken to prevent the guest administrator from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel privilege.
CREDITS
=======
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa202.patch xen-unstable, Xen 4.8.x, Xen 4.7.x
xsa202-4.6.patch Xen 4.6.x, Xen 4.5.x
xsa202-4.4.patch Xen 4.4.x
$ sha256sum xsa202*
057be742acfef200ba6f094a5dce486dd1c4e15013afe3efc963523ce2ec9cbb xsa202.patch
cd53dc8b761dc7eb60998ea2419c98af926aa62b4317dbef15f597f5554f9015 xsa202-4.4.patch
e007187639f5392a9256979504d50eff0ae38309a61524ea42c4150fab38b6f4 xsa202-4.6.patch
$
DEPLOYMENT DURING EMBARGO
=========================
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJYWm8TAAoJEIP+FMlX6CvZlekIALNmG5XBvAvY3Hpjwr/h+bh6
AJNof+4jH7WUsyV8NyJxBOtAxDBeGsQ5csoryIt8CoqPfL6lph5Y0eUMAa+aOGYB
FyMtWlKhyhoCjXcxhBCSAuHKldXyroZtzb6mx01nZSC8PbOCrnRzIGm/JLlnVS7b
WBol9ID3DRWlI42gwpzDh3l/64Rioyyk1I26Kqal56+CT9iPk/b2UwqVb9oGQPI0
iq8Lki5NAKwOQdRxQKEFnWMuwK2bJsuayM3K0Cl/DBckvcOstMkP543btZDZA/Uy
AiAOrTcBeDPmOoUVRpjwNEsFiiNeGgXV1R+FOcoZfWLdTKsn2igOtUkEekwVdAs=
=SNhC
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa202.patch --]
[-- Type: application/octet-stream, Size: 2691 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: force EFLAGS.IF on when exiting to PV guests
Guest kernels modifying instructions in the process of being emulated
for another of their vCPU-s may effect EFLAGS.IF to be cleared upon
next exiting to guest context, by converting the being emulated
instruction to CLI (at the right point in time). Prevent any such bad
effects by always forcing EFLAGS.IF on. And to cover hypothetical other
similar issues, also force EFLAGS.{IOPL,NT,VM} to zero.
This is XSA-202.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -109,6 +109,8 @@ compat_process_trap:
/* %rbx: struct vcpu, interrupts disabled */
ENTRY(compat_restore_all_guest)
ASSERT_INTERRUPTS_DISABLED
+ mov $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11d
+ and UREGS_eflags(%rsp),%r11d
.Lcr4_orig:
.skip .Lcr4_alt_end - .Lcr4_alt, 0x90
.Lcr4_orig_end:
@@ -144,6 +146,8 @@ ENTRY(compat_restore_all_guest)
(.Lcr4_orig_end - .Lcr4_orig), \
(.Lcr4_alt_end - .Lcr4_alt)
.popsection
+ or $X86_EFLAGS_IF,%r11
+ mov %r11d,UREGS_eflags(%rsp)
RESTORE_ALL adj=8 compat=1
.Lft0: iretq
_ASM_PRE_EXTABLE(.Lft0, handle_exception)
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -40,28 +40,29 @@ restore_all_guest:
testw $TRAP_syscall,4(%rsp)
jz iret_exit_to_guest
+ movq 24(%rsp),%r11 # RFLAGS
+ andq $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11
+ orq $X86_EFLAGS_IF,%r11
+
/* Don't use SYSRET path if the return address is not canonical. */
movq 8(%rsp),%rcx
sarq $47,%rcx
incl %ecx
cmpl $1,%ecx
- ja .Lforce_iret
+ movq 8(%rsp),%rcx # RIP
+ ja iret_exit_to_guest
cmpw $FLAT_USER_CS32,16(%rsp)# CS
- movq 8(%rsp),%rcx # RIP
- movq 24(%rsp),%r11 # RFLAGS
movq 32(%rsp),%rsp # RSP
je 1f
sysretq
1: sysretl
-.Lforce_iret:
- /* Mimic SYSRET behavior. */
- movq 8(%rsp),%rcx # RIP
- movq 24(%rsp),%r11 # RFLAGS
ALIGN
/* No special register assumptions. */
iret_exit_to_guest:
+ andl $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),24(%rsp)
+ orl $X86_EFLAGS_IF,24(%rsp)
addq $8,%rsp
.Lft0: iretq
_ASM_PRE_EXTABLE(.Lft0, handle_exception)
[-- Attachment #3: xsa202-4.4.patch --]
[-- Type: application/octet-stream, Size: 2265 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: force EFLAGS.IF on when exiting to PV guests
Guest kernels modifying instructions in the process of being emulated
for another of their vCPU-s may effect EFLAGS.IF to be cleared upon
next exiting to guest context, by converting the being emulated
instruction to CLI (at the right point in time). Prevent any such bad
effects by always forcing EFLAGS.IF on. And to cover hypothetical other
similar issues, also force EFLAGS.{IOPL,NT,VM} to zero.
This is XSA-202.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -173,6 +173,10 @@ compat_bad_hypercall:
/* %rbx: struct vcpu, interrupts disabled */
ENTRY(compat_restore_all_guest)
ASSERT_INTERRUPTS_DISABLED
+ mov $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11d
+ and UREGS_eflags(%rsp),%r11d
+ or $X86_EFLAGS_IF,%r11
+ mov %r11d,UREGS_eflags(%rsp)
RESTORE_ALL adj=8 compat=1
.Lft0: iretq
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -41,28 +41,29 @@ restore_all_guest:
testw $TRAP_syscall,4(%rsp)
jz iret_exit_to_guest
+ movq 24(%rsp),%r11 # RFLAGS
+ andq $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11
+ orq $X86_EFLAGS_IF,%r11
+
/* Don't use SYSRET path if the return address is not canonical. */
movq 8(%rsp),%rcx
sarq $47,%rcx
incl %ecx
cmpl $1,%ecx
- ja .Lforce_iret
+ movq 8(%rsp),%rcx # RIP
+ ja iret_exit_to_guest
cmpw $FLAT_USER_CS32,16(%rsp)# CS
- movq 8(%rsp),%rcx # RIP
- movq 24(%rsp),%r11 # RFLAGS
movq 32(%rsp),%rsp # RSP
je 1f
sysretq
1: sysretl
-.Lforce_iret:
- /* Mimic SYSRET behavior. */
- movq 8(%rsp),%rcx # RIP
- movq 24(%rsp),%r11 # RFLAGS
ALIGN
/* No special register assumptions. */
iret_exit_to_guest:
+ andl $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),24(%rsp)
+ orl $X86_EFLAGS_IF,24(%rsp)
addq $8,%rsp
.Lft0: iretq
[-- Attachment #4: xsa202-4.6.patch --]
[-- Type: application/octet-stream, Size: 2535 bytes --]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: force EFLAGS.IF on when exiting to PV guests
Guest kernels modifying instructions in the process of being emulated
for another of their vCPU-s may effect EFLAGS.IF to be cleared upon
next exiting to guest context, by converting the being emulated
instruction to CLI (at the right point in time). Prevent any such bad
effects by always forcing EFLAGS.IF on. And to cover hypothetical other
similar issues, also force EFLAGS.{IOPL,NT,VM} to zero.
This is XSA-202.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -174,6 +174,8 @@ compat_bad_hypercall:
/* %rbx: struct vcpu, interrupts disabled */
ENTRY(compat_restore_all_guest)
ASSERT_INTERRUPTS_DISABLED
+ mov $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11d
+ and UREGS_eflags(%rsp),%r11d
.Lcr4_orig:
.skip .Lcr4_alt_end - .Lcr4_alt, 0x90
.Lcr4_orig_end:
@@ -209,6 +211,8 @@ ENTRY(compat_restore_all_guest)
(.Lcr4_orig_end - .Lcr4_orig), \
(.Lcr4_alt_end - .Lcr4_alt)
.popsection
+ or $X86_EFLAGS_IF,%r11
+ mov %r11d,UREGS_eflags(%rsp)
RESTORE_ALL adj=8 compat=1
.Lft0: iretq
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -40,28 +40,29 @@ restore_all_guest:
testw $TRAP_syscall,4(%rsp)
jz iret_exit_to_guest
+ movq 24(%rsp),%r11 # RFLAGS
+ andq $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11
+ orq $X86_EFLAGS_IF,%r11
+
/* Don't use SYSRET path if the return address is not canonical. */
movq 8(%rsp),%rcx
sarq $47,%rcx
incl %ecx
cmpl $1,%ecx
- ja .Lforce_iret
+ movq 8(%rsp),%rcx # RIP
+ ja iret_exit_to_guest
cmpw $FLAT_USER_CS32,16(%rsp)# CS
- movq 8(%rsp),%rcx # RIP
- movq 24(%rsp),%r11 # RFLAGS
movq 32(%rsp),%rsp # RSP
je 1f
sysretq
1: sysretl
-.Lforce_iret:
- /* Mimic SYSRET behavior. */
- movq 8(%rsp),%rcx # RIP
- movq 24(%rsp),%r11 # RFLAGS
ALIGN
/* No special register assumptions. */
iret_exit_to_guest:
+ andl $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),24(%rsp)
+ orl $X86_EFLAGS_IF,24(%rsp)
addq $8,%rsp
.Lft0: iretq
[-- Attachment #5: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-12-21 12:01 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-21 12:01 Xen Security Advisory 202 (CVE-2016-10024) - x86 PV guests may be able to mask interrupts Xen.org security team
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.