Xen Security Advisory 202 (CVE-2016-10024) - x86 PV guests may be able to mask interrupts
Xen.org security team <[email protected]>
| Newsgroups | gmane.comp.emulators.xen.announce |
|---|---|
| Message-ID | <E1cJfaM-0003vY-CB__12847.3209370442$1482322213$gmane$org@xenbits.xenproject.org> |
-----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-----
_______________________________________________
Xen-announce mailing list
[email protected]
https://lists.xen.org/xen-announce
xsa202.patch
(application/octet-stream, 2.6 KB)
From: Jan Beulich <[email protected]> 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 <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> --- --- 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)
xsa202-4.4.patch
(application/octet-stream, 2.2 KB)
From: Jan Beulich <[email protected]> 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 <[email protected]> --- 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
xsa202-4.6.patch
(application/octet-stream, 2.5 KB)
From: Jan Beulich <[email protected]> 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 <[email protected]> --- 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