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

[Mathieu Tarral <mathieu.tarral@xxxxxxxxxxxxxx>]

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

> On Wed, Apr 24, 2019 at 9:34 AM Razvan Cojocaru
> rcojocaru@xxxxxxxxxxxxxxx wrote:
>
> > On 4/24/19 6:25 PM, Tamas K Lengyel wrote:
> >
> > > On Mon, Apr 22, 2019 at 6:00 PM Mathieu Tarral
> > > mathieu.tarral@xxxxxxxxxxxxxx wrote:
> > >
> > > > On Monday 22 April 2019 11:22, Razvan Cojocaru 
> > > > rcojocaru@xxxxxxxxxxxxxxx wrote:
> > > >
> > > > > On 4/22/19 1:26 AM, Mathieu Tarral wrote:
> > > > >
> > > > > > The problem is that RtlUserThreadStart is paged-out, so i'm trying 
> > > > > > to reach it via singlestepping as a backup solution.
> > > > >
> > > > > FWIW, you can just use xc_hvm_inject_trap() with a TRAP_page_fault
> > > > > parameter to cause the OS to bring a paged out page back into main 
> > > > > memory.
> > > >
> > > > The problem is that i'm fully based on LibVMI, which doesn't provide an 
> > > > API for page injection yet.
> > > > I think Tamas was waiting for a full support of pagefault injection on 
> > > > Xen before opening an API.
> > > > Maybe we should open an issue to track the progress about it.
> > > > Thanks anyway for the suggestion !
> > >
> > > Not having a LibVMI wrapper should not prevent you from using a libxc
> > > function directly. There are many corner-cases regarding when it is
> > > safe to inject a pagefault into the guest to bring back pages and that
> > > logic is not trivial enough to be implemented in LibVMI. It's way too
> > > specific to the usecase to decide when it's safe to do that. So in
> > > this case, if you know you are in ring3 of your target process you can
> > > just call the libxc function directly.
> >
> > That's very very true, however I think we should assume that libraries
> > such as libvmi and libbdvmi are used by client code smart enough to
> > figure out, using said libraries, enough things about what's appropriate
> > (or not) to do, and let them do it rather than second-guess them.
> > Hence, in libbdvmi I've wrapped that, and added a comment basically
> > saying what you're saying above:
> > https://github.com/bitdefender/libbdvmi/blob/master/src/xendriver.cpp#L542
> > If we end up having the client code call backend-specific code directly
> > we're not, after all, really abstracting it with our wrapper libraries.
>
> If someone adds that wrapper to LibVMI I wouldn't veto it - but it's
> also a function that I'm 100% expecting will generate a lot of
> confusion and whining about it not working in all cases. So I chose
> not to add it myself because of that. ¯\(ツ)/¯

Tamas, i'm using Python so i can't directly call libxc.

Also, and as Razvan said, I would like to stick with a coherent and clearly 
defined abstractions layers, first because it will allow me to be 
hypervisor-agnostic in the future, if new LibVMI drivers are developed, and 
then just for the sack of API consistency.



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