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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

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

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