* Xen Security Advisory 265 (CVE-2018-12893) - x86: #DB exception safety check can be triggered by a guest
@ 2018-06-27 21:03 Xen.org security team
0 siblings, 0 replies; only message in thread
From: Xen.org security team @ 2018-06-27 21:03 UTC (permalink / raw)
To: xen-announce, xen-devel, xen-users, oss-security; +Cc: Xen.org security team
[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Xen Security Advisory CVE-2018-12893 / XSA-265
version 3
x86: #DB exception safety check can be triggered by a guest
UPDATES IN VERSION 3
====================
Public release.
ISSUE DESCRIPTION
=================
One of the fixes in XSA-260 added some safety checks to help prevent Xen
livelocking with debug exceptions. Unfortunately, due to an oversight, at
least one of these safety checks can be triggered by a guest.
IMPACT
======
A malicious PV guest can crash Xen, leading to a Denial of Service.
VULNERABLE SYSTEMS
==================
All Xen systems which have applied the XSA-260 fix are vulnerable.
Only x86 systems are vulnerable. ARM systems are not vulnerable.
Only x86 PV guests can exploit the vulnerability. x86 HVM and PVH
guests cannot exploit the vulnerability.
An attacker needs to be able to control hardware debugging facilities to
exploit the vulnerability, but such permissions are typically available
to unprivileged users.
MITIGATION
==========
Running only x86 HVM or PVH guests will avoid the vulnerability.
CREDITS
=======
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==========
Applying the appropriate attached patch resolves this issue.
xsa265.patch xen-unstable, Xen 4.10.x, 4.9.x, 4.8.x
xsa265-4.7.patch Xen 4.7.x, 4.6.x
$ sha256sum xsa265*
3eb66ed7251dcc4259eeffe608b2747857e269307d894a1cb950973420184aa7 xsa265.patch
00faf2a4159698b6540565ece06de103c3547855e2084324ca44772b8a24aa18 xsa265-4.7.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
iQEcBAEBCAAGBQJbM+5JAAoJEIP+FMlX6CvZtSgIAMF8d/3Jor6b0EbW55JSLh76
56I8QfkqX4Xv/yWri3sXGJmPz7Af/qjDO+Ix5IScq54ugN5C8z7OBcbXFpX1WxNJ
xCv6QjsbPmGCZHsT+NdWrl/ac6ZH3xlhE+S1awQ+9SkC+r6bRH/iROO+4DhpYQde
CGoyYIwFq2VJoovh8lWHMsVl8VUXisyDk3bPK17VlAEFF1LuOkaan1UGEKRsciGX
12IlNw/I6c8a85wWpFtph1AOVZfrodWdwyj8vgLY3MHnEs+86/cm5O4+GxKHezHf
P5dJDZ38HBPRL1qC+yFRV2sLxLgrc7fYlSWr3/xtOGo23aDLjCvS+FsMfIpyjPQ=
=sf+j
-----END PGP SIGNATURE-----
[-- Attachment #2: xsa265.patch --]
[-- Type: application/octet-stream, Size: 4564 bytes --]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86: Refine checks in #DB handler for faulting conditions
One of the fix for XSA-260 (c/s 75d6828bc2 "x86/traps: Fix handling of #DB
exceptions in hypervisor context") added some safety checks to help avoid
livelocks of #DB faults.
While a General Detect #DB exception does have fault semantics, hardware
clears %dr7.gd on entry to the handler, meaning that it is actually safe to
return to. Furthermore, %dr6.gd is guest controlled and sticky (never cleared
by hardware). A malicious PV guest can therefore trigger the fatal_trap() and
crash Xen.
Instruction breakpoints are more tricky. The breakpoint match bits in %dr6
are not sticky, but the Intel manual warns that they may be set for
non-enabled breakpoints, so add a breakpoint enabled check.
Beyond that, because of the restriction on the linear addresses PV guests can
set, and the fault (rather than trap) nature of instruction breakpoints
(i.e. can't be deferred by a MovSS shadow), there should be no way to
encounter an instruction breakpoint in Xen context. However, for extra
robustness, deal with this situation by clearing the breakpoint configuration,
rather than crashing.
This is XSA-265
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e79ca88..3e05cf1 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1809,6 +1809,13 @@ void do_debug(struct cpu_user_regs *regs)
if ( !guest_mode(regs) )
{
+ /*
+ * !!! WARNING !!!
+ *
+ * %dr6 is mostly guest controlled at this point. Any decsions base
+ * on its value must be crosschecked with non-guest controlled state.
+ */
+
if ( regs->eflags & X86_EFLAGS_TF )
{
/* In SYSENTER entry path we can't zap TF until EFLAGS is saved. */
@@ -1830,33 +1837,44 @@ void do_debug(struct cpu_user_regs *regs)
* Check for fault conditions. General Detect, and instruction
* breakpoints are faults rather than traps, at which point attempting
* to ignore and continue will result in a livelock.
+ *
+ * However, on entering the #DB handler, hardware clears %dr7.gd for
+ * us (as confirmed by the earlier %dr6 accesses succeeding), meaning
+ * that a real General Detect exception is restartable.
+ *
+ * PV guests are not permitted to point %dr{0..3} at Xen linear
+ * addresses, and Instruction Breakpoints (being faults) don't get
+ * delayed by a MovSS shadow, so we should never encounter one in
+ * hypervisor context.
+ *
+ * If however we do, safety measures need to be enacted. Use a big
+ * hammer and clear all debug settings.
*/
- if ( dr6 & DR_GENERAL_DETECT )
- {
- printk(XENLOG_ERR "Hit General Detect in Xen context\n");
- fatal_trap(regs, 0);
- }
-
if ( dr6 & (DR_TRAP3 | DR_TRAP2 | DR_TRAP1 | DR_TRAP0) )
{
- unsigned int bp, dr7 = read_debugreg(7) >> DR_CONTROL_SHIFT;
+ unsigned int bp, dr7 = read_debugreg(7);
for ( bp = 0; bp < 4; ++bp )
{
if ( (dr6 & (1u << bp)) && /* Breakpoint triggered? */
- ((dr7 & (3u << (bp * DR_CONTROL_SIZE))) == 0) /* Insn? */ )
+ (dr7 & (3u << (bp * DR_ENABLE_SIZE))) && /* Enabled? */
+ ((dr7 & (3u << ((bp * DR_CONTROL_SIZE) + /* Insn? */
+ DR_CONTROL_SHIFT))) == DR_RW_EXECUTE) )
{
+ ASSERT_UNREACHABLE();
+
printk(XENLOG_ERR
"Hit instruction breakpoint in Xen context\n");
- fatal_trap(regs, 0);
+ write_debugreg(7, 0);
+ break;
}
}
}
/*
- * Whatever caused this #DB should be a trap. Note it and continue.
- * Guests can trigger this in certain corner cases, so ensure the
- * message is ratelimited.
+ * Whatever caused this #DB should be restartable by this point. Note
+ * it and continue. Guests can trigger this in certain corner cases,
+ * so ensure the message is ratelimited.
*/
gprintk(XENLOG_WARNING,
"Hit #DB in Xen context: %04x:%p [%ps], stk %04x:%p, dr6 %lx\n",
[-- Attachment #3: xsa265-4.7.patch --]
[-- Type: application/octet-stream, Size: 4558 bytes --]
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86: Refine checks in #DB handler for faulting conditions
One of the fix for XSA-260 (c/s 75d6828bc2 "x86/traps: Fix handling of #DB
exceptions in hypervisor context") added some safety checks to help avoid
livelocks of #DB faults.
While a General Detect #DB exception does have fault semantics, hardware
clears %dr7.gd on entry to the handler, meaning that it is actually safe to
return to. Furthermore, %dr6.gd is guest controlled and sticky (never cleared
by hardware). A malicious PV guest can therefore trigger the fatal_trap() and
crash Xen.
Instruction breakpoints are more tricky. The breakpoint match bits in %dr6
are not sticky, but the Intel manual warns that they may be set for
non-enabled breakpoints, so add a breakpoint enabled check.
Beyond that, because of the restriction on the linear addresses PV guests can
set, and the fault (rather than trap) nature of instruction breakpoints
(i.e. can't be deferred by a MovSS shadow), there should be no way to
encounter an instruction breakpoint in Xen context. However, for extra
robustness, deal with this situation by clearing the breakpoint configuration,
rather than crashing.
This is XSA-265
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 731d054..d528be9 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3872,6 +3872,13 @@ void do_debug(struct cpu_user_regs *regs)
if ( !guest_mode(regs) )
{
+ /*
+ * !!! WARNING !!!
+ *
+ * %dr6 is mostly guest controlled at this point. Any decsions base
+ * on its value must be crosschecked with non-guest controlled state.
+ */
+
if ( regs->eflags & X86_EFLAGS_TF )
{
/* In SYSENTER entry path we can't zap TF until EFLAGS is saved. */
@@ -3893,33 +3900,44 @@ void do_debug(struct cpu_user_regs *regs)
* Check for fault conditions. General Detect, and instruction
* breakpoints are faults rather than traps, at which point attempting
* to ignore and continue will result in a livelock.
+ *
+ * However, on entering the #DB handler, hardware clears %dr7.gd for
+ * us (as confirmed by the earlier %dr6 accesses succeeding), meaning
+ * that a real General Detect exception is restartable.
+ *
+ * PV guests are not permitted to point %dr{0..3} at Xen linear
+ * addresses, and Instruction Breakpoints (being faults) don't get
+ * delayed by a MovSS shadow, so we should never encounter one in
+ * hypervisor context.
+ *
+ * If however we do, safety measures need to be enacted. Use a big
+ * hammer and clear all debug settings.
*/
- if ( dr6 & DR_GENERAL_DETECT )
- {
- printk(XENLOG_ERR "Hit General Detect in Xen context\n");
- fatal_trap(regs);
- }
-
if ( dr6 & (DR_TRAP3 | DR_TRAP2 | DR_TRAP1 | DR_TRAP0) )
{
- unsigned int bp, dr7 = read_debugreg(7) >> DR_CONTROL_SHIFT;
+ unsigned int bp, dr7 = read_debugreg(7);
for ( bp = 0; bp < 4; ++bp )
{
if ( (dr6 & (1u << bp)) && /* Breakpoint triggered? */
- ((dr7 & (3u << (bp * DR_CONTROL_SIZE))) == 0) /* Insn? */ )
+ (dr7 & (3u << (bp * DR_ENABLE_SIZE))) && /* Enabled? */
+ ((dr7 & (3u << ((bp * DR_CONTROL_SIZE) + /* Insn? */
+ DR_CONTROL_SHIFT))) == DR_RW_EXECUTE) )
{
+ ASSERT_UNREACHABLE();
+
printk(XENLOG_ERR
"Hit instruction breakpoint in Xen context\n");
- fatal_trap(regs);
+ write_debugreg(7, 0);
+ break;
}
}
}
/*
- * Whatever caused this #DB should be a trap. Note it and continue.
- * Guests can trigger this in certain corner cases, so ensure the
- * message is ratelimited.
+ * Whatever caused this #DB should be restartable by this point. Note
+ * it and continue. Guests can trigger this in certain corner cases,
+ * so ensure the message is ratelimited.
*/
gprintk(XENLOG_WARNING,
"Hit #DB in Xen context: %04x:%p [%ps], stk %04x:%p, dr6 %lx\n",
[-- Attachment #4: Type: text/plain, Size: 157 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] only message in thread
only message in thread, other threads:[~2018-06-27 21:03 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-27 21:03 Xen Security Advisory 265 (CVE-2018-12893) - x86: #DB exception safety check can be triggered by a guest 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.