Re: [Xen-devel] [PATCH RFC V3 4/5] xen, libxc: Request page fault injection via libxc

[Andrei LUTAS <vlutas@xxxxxxxxxxxxxxx>]

Hello, everybody!

The logic with the #PF injection goes like this:
- The memory introspection engine wants to inspect (for whatever reason) a
  virtual page X insidevirtual address space Y(inside user-mode, although
  with proper knowledge about the guest kernel,one can also inject #PF 
inside
  kernel-mode on Windows - proper IRQL, working set trim inactive, etc.)
- The memory introspection engine will write-protect (via EPT) the Page 
Table
  Entries responsible for thetranslation of X to the Guest Physical 
Address Z
- The memory introspection engine requests the #PF injection
- The memory introspection engine patiently waits until the PTE 
corresponding
  tothe virtualpage Xis written - this means that the page has been 
swapped
  in, either due to our synthetic #PF, orbecause the guest OS accessed it
- We now need to analyse the faulting instruction in order to extract the
  written value, which containsthe address of the guest-physical page
  containing the datawe want to analyse - W - what X will translate to 
after
  the swap-in operation will be complete; we basically need to map W,
  without doing a new translation for X. No pause of the entire domain is
  normally needed for this.

Hopefully this covers in more detail the actual use-case of the #PF 
injection
and how it interacts with the introspection engine.

Thanks!
Andrei

On 7/23/2014 6:13 PM, Razvan Cojocaru wrote:
> On 07/23/2014 05:27 PM, Tamas Lengyel wrote:
> >      > wrapped into an unlikely(). But isn't this a bit of an overkill at
> >      every
> >      > VMENTER for every domain? Surely there are less invasive mechanisms to
> >      > trigger a VMEXIT when you know your VM will be in a state where
> >      you can
> >      > inject your page fault, without incurring an overhead for every
> >      domain.
> >
> >      It's not much of an overhead, basically if
> >      d->arch.hvm_domain.fault_info.virtual_address == 0 (which is almost
> >      always the case), nothing happens.
> >
> >
> > Since the majority of the domains will never use it, even a tiny
> > overhead adds up, especially over time. It would be a lot cleaner to
> > trap the execution of the VM at the moment when it is safe to inject the
> > page fault instead. For example you could just mark the process' code
> > pages non-executable in the EPT, catch the violations, and if the
> > conditions are met inject your pagefault.
> Ufortunately it's more complicated than that. Our application wants to
> be able to inject page faults at process initialization time, for PEB,
> etc., where we're not necessarily talking about a process executing code.
>
> >      > Also, it might make sense to perform some sanity checks on the
> >      vaddr and
> >      > address space before injection (ie. is the page really swapped out).
> >      > There is no guarantee that the page is still swapped out, even if you
> >      > checked before issuing xc_domain_set_pagefault_info, unless the domain
> >      > had been paused for both checking and setting.
> >
> >      As said above, the particular VCPU is in our case paused and waiting for
> >      a mem_event reply. The assumption is that other clients will work under
> >      similar circumstances, however it's always a good idea to check
> >      everything that can be checked.
> >
> >
> > I don't think having just the VCPU paused is enough, another still
> > active VCPU might still swap the page back, so you would really need to
> > have the entire VM paused for this to be safe. Furthermore, if there are
> > any limitations/assumptions like this about the intended use of the
> > function, describing them in a comment in xenctrl.h would be appropriate.
> A typical use case for this is:
>
> 1. the application figures out that it needs a swapped out page;
> 2. the application tries to bring it in (via the code in this patch);
> 3. the application maps the page.
>
> Now, if the application fails step 3, it might go back to step 2 until
> it succeeds, or it might give up after some retries. If, however, it
> succeeds, the mapped page should be safe to use until unmapped via libxc.
>
> I would add that in practice this problem never occured with any of the
> HVM Windows guests we've used for testing. The OS doesn't seem likely to
> immediately swap out a page that's just been brought in.
>
> If this is a concern, maybe I could simply add a comment in xenctrl.h
> that would say that the new function is only to be used while the domain
> is paused. I seem to recall having seen such comments there for other
> libxc functions.
>
>
> Thanks,
> Razvan Cojocaru
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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