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

[Andrei LUTAS <vlutas@bitdefender.com>]

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@lists.xen.org
> http://lists.xen.org/xen-devel
>