Re: [Xen-devel] VMI: singlestep event not received

[Mathieu Tarral <mathieu.tarral@xxxxxxxxxxxxxx>]

On Wednesday 24 April 2019 17:35, Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx> 
wrote:

> On Sun, Apr 21, 2019 at 4:27 PM Mathieu Tarral
> mathieu.tarral@xxxxxxxxxxxxxx wrote:
>
> > Hi,
> > I'm having an issue with Xen's VMI subsystem.
> > My goal is to build a small debugger that can break at an application's 
> > entrypoint
> > on Windows XP, when a new process is being created.
> > To accomplish this, I first set a software breakpoint on KiThreadStartup 
> > (ntoskrnl.exe),
> > then on RtlUserThreadStart (ntdll.dll).
> > The problem is that RtlUserThreadStart is paged-out, so i'm trying to reach 
> > it via singlestepping as a backup solution.
> > To my surprise, it didn't work as expected, since my application just 
> > hanged, waiting for the next singlestep event:
> > --Waiting for xen events...(0 ms)
> > Disabling single step on vcpu: 0
> > --Removing MTF flag from vcpu 0
> > --Shutting down single step on domain 1
> > --Removing MTF flag from vcpu 0
> > --Starting single step on domain 1
> > Enabling single step
> > INFO:WindowsDebugContext:[105] at: 0x806d32d6
> > Disabling single step on vcpu: 0
> > --Removing MTF flag from vcpu 0
> > --Shutting down single step on domain 1
> > --Removing MTF flag from vcpu 0
> > --Starting single step on domain 1
> > --Setting MTF flag on vcpu 0
> > Enabling single step
> > --Waiting for xen events...(1000 ms)
> > --Waiting for xen events...(0 ms)
> > Disabling single step on vcpu: 0
> > --Removing MTF flag from vcpu 0
> > --Shutting down single step on domain 1
> > --Removing MTF flag from vcpu 0
> > --Starting single step on domain 1
> > Enabling single step
> > INFO:WindowsDebugContext:[106] at: 0x806d32dc
> > Disabling single step on vcpu: 0
> > --Removing MTF flag from vcpu 0
> > --Shutting down single step on domain 1
> > --Removing MTF flag from vcpu 0
> > --Starting single step on domain 1
> > --Setting MTF flag on vcpu 0
> > Enabling single step
> > --Waiting for xen events...(1000 ms)
> > --Waiting for xen events...(1000 ms)
> > --Waiting for xen events...(1000 ms)
> > --Waiting for xen events...(1000 ms)
> > --Waiting for xen events...(1000 ms)
> > --Waiting for xen events...(1000 ms)
> > --Waiting for xen events...(1000 ms)
> > The reason why i'm disabling end enabling the singlestep successively is 
> > because i already
> > have a libvmi singlestep event registered, with the MTF flag disabled.
> > I only use it for breakpoint recoil situations.
> > It's a limitation of the libvmi API where you cannot modified a registered 
> > event to enable singlestep at will.
>
> I'm not entirely sure what you mean here (and perhaps that's a
> discussion to be moved to the LibVMI issues page). If you already have
> an event registered for singlestepping why would you want to disable
> it just to re-enable it? If it's because you just have the handler
> registered without MTF actually active, that's specifically made for
> the situation where turn on/off MTF using the VM_EVENT_RESPONSE_FLAG.

The reason is because i needed an on-demand activation of MTF, without being in 
an event callback.

Let's say my GDB client asks me to do one singlestep.
I will need to register a new singlestep event, enabled, listen
one event and then return.

The problem is that I already have my singlestep event for breakpoint recoiling 
purposes which is registered.

That's the reason I'm unregistering this recoil singlestep event and 
reregistering it afterwards, because I can't "reuse" it:
https://github.com/Wenzel/pyvmidbg/blob/master/vmidbg/breakpoint.py#L79

I actually discussed it with you here:
https://github.com/libvmi/libvmi/issues/665

> Also, using MTF to reach parts of the code that are several hundred
> instructions down the pipe will most likely not work due to the
> extreme overhead it adds. You are more likely to get an interrupt and
> land somewhere in the kernel long before you reach your target. At
> least that has been my experience. You likely want to investigate
> other options, such as what Razvan recommended.

I agree, it was a backup solution from the beginning.
I would like to use hardware breakpoint instead, so I won't have to deal with 
pagefault injection.

As I reported to you, I implemented this solution already:
https://github.com/Wenzel/pyvmidbg/blob/entrypoint.hwbreakpoint/vmidbg/windowsdebugcontext.py#L210

But as soon as I restart my process, DR7 gets rewritten at some point by 
Windows, maybe in the NtContinue syscall where it sets a new Thread CONTEXT.

Anyway, i would need to intercept a MOV-TO-DRx to prevent Windows from 
disabling my hardware breakpoints :)

As I understood, this was not exposed by the Xen VMI API yet:
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/vm_event.h;h=b2bafc0d77f9758e42b0d53c05a7e6bb86c86686;hb=HEAD#l154

Mathieu


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel