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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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@citrix.com>

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)

      case VMEXIT_EXCEPTION_DB:
          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();
          break;

      case VMEXIT_EXCEPTION_BP:

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.

~Andrew