[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Xen Security Advisory 259 - x86: PV guest may crash Xen with XPTI
From: Xen.org security team <security () xen ! org>
Date: 2018-04-25 12:03:36
Message-ID: E1fBJ96-00044j-0I () xenbits ! xenproject ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory XSA-259
version 2
x86: PV guest may crash Xen with XPTI
UPDATES IN VERSION 2
====================
Public release.
ISSUE DESCRIPTION
=================
The workaround for the Meltdown vulnerability (XSA-254) failed to deal
with an error code path connecting the INT 80 handling with general
exception handling. This results in an unconditional write attempt of
the value zero to an address near 2^64, in cases where a PV guest has no
handler installed for INT 80 on one of its vCPU-s.
IMPACT
======
A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host.
VULNERABLE SYSTEMS
==================
All Xen versions which the XSA-254 fixes were applied to are vulnerable.
Only x86 systems are vulnerable. ARM systems are not vulnerable.
Only x86 PV guests can exploit the vulnerability. x86 PVH and HVM
guests cannot exploit the vulnerability.
MITIGATION
==========
Running only PVH or HVM guests avoids the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa259.patch xen-unstable, Xen 4.10.x ... xen 4.7.x
xsa259-4.6.patch Xen 4.6.x
$ sha256sum xsa259*
5c14a90af066c952974324b361e2a428c280f876b854f0c85a78e8579054a4d1 xsa259.meta
ff2efb5eb2502ded988d0aa15351030a15494a9e2223eafbb88377a8e4d39dcb xsa259.patch
c40bc8802077cf73f8393fb50574b7c7efbc4d127e202b0ebd757d34aa07aac3 xsa259-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
iQEcBAEBCAAGBQJa4G58AAoJEIP+FMlX6CvZrqIH+QFfC5NOoFhVZAChTU0WQ7U6
UwP7yEyLeY15VrGb4YvwzKhvTNwsRRiYTbTNB/QjAkrUkMRhBiUIz7mQqBl0Vc/N
4zblt+YNdDMjhCllTjvtYU6OJzbsqvEBByB4mFrz6fxfZiuXIbOnMUOxLHRRdXLR
6JR8+4RrheKNl9DF6lmLj50d3G/fKrNLY9id8VcDG1TGIB6E1CbJ6gibw7FiYDSq
PETa5O1szo2FO2yY+xcMzzGLHv+oVeKZnmuq9KYtP7Q+G823Twz1RE6rTBEjwhs9
sDGUlgZ48QVfSzer10syzyeX0p9hLHyKhlJnCrmCiywvKq68/uVexZFNcOKRPtE=
=n+01
-----END PGP SIGNATURE-----
["xsa259.meta" (application/octet-stream)]
["xsa259.patch" (application/octet-stream)]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: fix slow int80 path after XPTI additions
For the int80 slow path to jump to handle_exception_saved, %r14 needs to
be set up suitably for XPTI purposes. This is because of the difference
in nature between the int80 path (which is synchronous WRT guest
actions) and the exception path which is potentially asynchronous.
This is XSA-259.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -396,6 +396,12 @@ int80_slow_path:
movl $TRAP_gp_fault,UREGS_entry_vector(%rsp)
/* A GPF wouldn't have incremented the instruction pointer. */
subq $2,UREGS_rip(%rsp)
+ /*
+ * While we've cleared xen_cr3 above already, normal exception handling
+ * code has logic to restore the original value from %r15. Therefore we
+ * need to set up %r14 here, while %r15 is required to still be zero.
+ */
+ GET_STACK_END(14)
jmp handle_exception_saved
/* create_bounce_frame & helpers don't need to be in .text.entry */
["xsa259-4.6.patch" (application/octet-stream)]
From: Jan Beulich <jbeulich@suse.com>
Subject: x86: fix slow int80 path after XPTI additions
For the int80 slow path to jump to handle_exception_saved, %r14 needs to
be set up suitably for XPTI purposes. This is because of the difference
in nature between the int80 path (which is synchronous WRT guest
actions) and the exception path which is potentially asynchronous.
This is XSA-259.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -442,6 +442,12 @@ int80_slow_path:
movl $TRAP_gp_fault,UREGS_entry_vector(%rsp)
/* A GPF wouldn't have incremented the instruction pointer. */
subq $2,UREGS_rip(%rsp)
+ /*
+ * While we've cleared xen_cr3 above already, normal exception handling
+ * code has logic to restore the original value from %r15. Therefore we
+ * need to set up %r14 here, while %r15 is required to still be zero.
+ */
+ GET_STACK_BASE(%r14)
jmp handle_exception_saved
/* CREATE A BASIC EXCEPTION FRAME ON GUEST OS STACK: */
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic