Re: [Xen-users] [Xen-devel] xc_hvm_inject_trap() failing for int3 traps under Xen 4.2.2

[Tim Deegan <tim@xxxxxxx>]

At 16:57 +0000 on 10 Jun (1370883430), Antony Saba wrote:
> On 06/10/2013 05:29 AM, George Dunlap wrote:
> > On Fri, Jun 7, 2013 at 4:51 PM, Steven Maresca <steve@xxxxxxxxxxxx> wrote:
> >> Tony,
> >>
> >> I can confirm INT3 re-injection does work on 4.2.x and 4.3, but the
> >> problem you observed is certainly present.
> >>
> >> As suggested, it was necessary when invoking xc_hvm_inject_trap to
> >> specify the 1-byte instruction length for 0xCC (without which the VM
> >> was intentionally crashed by Xen).
> >>
> >> In this case, there's no need to inspect the actual instruction
> >> referenced by the IP because it seems the trap is only fired for the
> >> one-byte variant (0xCD03 of course works properly, but no event is
> >> emitted).
> >>
> >> Mirroring your experience with 4.1.2, for my testing on 4.2+ the
> >> return of xc_hvm_inject_trap is also always non-zero even for
> >> successful re-injection..whether that's intended is another question.
> >>
> >> Steve
> >>
> >> NOTE: I would definitely consider it a bug that the xen-access.c
> >> example crashes guests when attempting to use the INT3
> >> mode...non-critical for most users, but nevertheless.
> > 
> > I'm having a bit of trouble finding the conclusion here.
> > 
> > So it seems the problem is that if a *guest* is doing int3
> > instructions, that will interfere with the ability of the debugger to
> > use int3 to do introspection -- is that right?
> > 
> Yes, that is one scenario.  The one I was experiencing was some
> (apparently legitimate) background process on a Windows 7 x64 guest that
> just always executes an int3 when it runs.
> 
> I'll try to summarize, someone please correct me if I'm wrong.  There
> are 2 things going on here:
> 
> 1) The patch previously posted by AP is the correct way to call
> xc_hvm_inject_trap() for int 3 (0xcc).  That is, the instruction_length
> parameter must be set to 1.

Not necessarily, AFAICT -- you'd need to fetch and decode the
instruction in order to detect prefix bytes (other than LOCK, which is
explicitly disallowed).

> 2) xc_hvm_inject_trap() always returns a negative value, even when there
> is not a problem and the guest receives the trap as expected.  There
> hasn't been a clarification as to whether it's supposed to return
> non-negative, but one would assume that it should because of the way the
> xen-access.c example checks for it.

That looks like a hypervisor bug to me: does this (untested) patch fix
it for you?

commit 67b9272fcedcb5dc73cc77a2adf580f2572117d7
Author: Tim Deegan <tim@xxxxxxx>
Date:   Mon Jun 10 19:35:34 2013 +0100

    x86/hvm: Fix HVMOP_inject_trap return value on success.
    
    Reported-by: Antony Saba <Antony.Saba@xxxxxxxxxxxx>
    Signed-off-by: Tim Deegan <tim@xxxxxxx>

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ce44bff..6c86fc2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4430,6 +4430,7 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
             v->arch.hvm_vcpu.inject_trap.error_code = tr.error_code;
             v->arch.hvm_vcpu.inject_trap.insn_len = tr.insn_len;
             v->arch.hvm_vcpu.inject_trap.cr2 = tr.cr2;
+            rc = 0;
         }
 
     param_fail8:




_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users