[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-changelog] [xen staging-4.8] x86/vtx: Work around SingleStep + STI/MovSS VMEntry failures



commit 76dad2eb498296fbe4e3ecb8147cd1c2881963bf
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Wed Dec 11 15:58:03 2019 +0100
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Wed Dec 11 15:58:03 2019 +0100

    x86/vtx: Work around SingleStep + STI/MovSS VMEntry failures
    
    See patch comment for technical details.
    
    Concerning the timeline, this was first discovered in the aftermath of
    XSA-156 which caused #DB to be intercepted unconditionally, but only in
    its SingleStep + STI form which is restricted to privileged software.
    
    After working with Intel and identifying the problematic vmentry check,
    this workaround was suggested, and the patch was posted in an RFC
    series.  Outstanding work for that series (not breaking Introspection)
    is still pending, and this fix from it (which wouldn't have been good
    enough in its original form) wasn't committed.
    
    A vmentry failure was reported to xen-devel, and debugging identified
    this bug in its SingleStep + MovSS form by way of INT1, which does not
    involve the use of any privileged instructions, and proving this to be a
    security issue.
    
    This is XSA-308
    
    Reported-by: HÃ¥kon Alstadheim <hakon@xxxxxxxxxxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    master commit: 1d3eb8259804e5bec991a3462d69ba6bd80bb40e
    master date: 2019-12-11 14:09:30 +0100
---
 xen/arch/x86/hvm/vmx/vmx.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e95b4c2d1f..9a8807e53e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3760,6 +3760,42 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
             HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
             __restore_debug_registers(v);
             write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
+
+            /*
+             * Work around SingleStep + STI/MovSS VMEntry failures.
+             *
+             * We intercept #DB unconditionally to work around CVE-2015-8104 /
+             * XSA-156 (guest-kernel induced host DoS).
+             *
+             * STI/MovSS shadows block/defer interrupts/exceptions (exact
+             * details are complicated and poorly documented).  Debug
+             * exceptions delayed for any reason are stored in the
+             * PENDING_DBG_EXCEPTIONS field.
+             *
+             * The falling edge of PENDING_DBG causes #DB to be delivered,
+             * resulting in a VMExit, as #DB is intercepted.  The VMCS still
+             * reports blocked-by-STI/MovSS.
+             *
+             * The VMEntry checks when EFLAGS.TF is set don't like a VMCS in
+             * this state.  Despite a #DB queued in VMENTRY_INTR_INFO, the
+             * state is rejected as DR6.BS isn't pending.  Fix this up.
+             */
+            if ( unlikely(regs->eflags & X86_EFLAGS_TF) )
+            {
+                unsigned long int_info;
+
+                __vmread(GUEST_INTERRUPTIBILITY_INFO, &int_info);
+
+                if ( int_info & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) 
)
+                {
+                    unsigned long pending_dbg;
+
+                    __vmread(GUEST_PENDING_DBG_EXCEPTIONS, &pending_dbg);
+                    __vmwrite(GUEST_PENDING_DBG_EXCEPTIONS,
+                              pending_dbg | DR_STEP);
+                }
+            }
+
             if ( !v->domain->debugger_attached )
             {
                 unsigned long insn_len = 0;
--
generated by git-patchbot for /home/xen/git/xen.git#staging-4.8

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.