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

[Xen-devel] AMD #DB interception (was [PATCH] x86/vmx: Fix injection of #DB traps following XSA-165)

On 24/12/2015 18:23, Andrew Cooper wrote:
Most debug exceptions are traps rather than faults.  Blindly re-injecting them
as hardware exception causes the instruction pointer in the exception frame
to point at the target instruct, rather than after it.  This in turn breaks
debuggers in the guests.

Introduce a helper which copies VM_EXIT_INTR_INTO to VM_ENTRY_INTR_INFO, and
use it to mirror the intercepted interrupt back to the guest.  As part of
doing so, introduce vmx_intr_info_t with a bitfield representation of an
INTR_INFO field.

Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

In principle, the same logical bug exists for SVM, but things are a little more complicated.

In VT-x, all exception intercepts have fault semantics, but for SVM, exception intercepts for traps take place after the trapped instruction has completed.

Therefore, despite being conceptually incorrect, the XSA-165 patch of:

@@ -2434,8 +2435,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)

         if ( !v->domain->debugger_attached )
-            goto unexpected_exit_type;
-        domain_pause_for_debugger();
+            hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+        else
+            domain_pause_for_debugger();


is correct, as whether the intercepted exception was a trap or a fault, it must be in-injected at the current %rip, as well as needing nrip = rip.

Could I please get a second opinion?

I don't actually have a unit test for this at the moment (my existing unit test uses ICEBP for #BP traps, which have different intercept semantics in SVM), but I will be working on one in due course.


Xen-devel mailing list



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