Re: [Xen-devel] xc_hvm_inject_trap() races

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.11.16 at 10:53, <vlutas@xxxxxxxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 2 November, 2016 11:38
>> >>> On 02.11.16 at 10:13, <vlutas@xxxxxxxxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: 2 November, 2016 10:50
>> >> >>> On 01.11.16 at 23:17, <vlutas@xxxxxxxxxxxxxxx> wrote:
>> >> > We don't really care when and how the #PF is handled. We don't care
>> >> > if the page is paged out at some random point. What we do know is
>> >> > that at a certain point in the future, the page will be swapped in;
>> >> > how do we know when? The OS will write the guest page tables, at
>> >> > which point we can inspect the physical page itself (so you can see
>> >> > here why we don't care about the page being swapped out sometime in
>> >> > the future). So we really _can_ lift any restriction we want at that 
>> >> > point.
>> >>
>> >> Hmm, I'm having difficulty seeing the supposedly broken flow of
>> >> events
>> >> here: Earlier it was said that #PF injection would be a result of EPT
>> >> event processing. Here you say that the lifting of the restrictions
>> >> would be a result of seeing the guest modify its page tables (which
>> >> would in turn be a result of the #PF actually having arrived in the
>> >> guest). So if (with this, and as you say
>> >> above) you don't care when the #PF gets handled, where's the original
>> >> problem?
>> >
>> > That's not what I wanted to say, sorry if it was unclear. What I'm
>> > trying to say is that the decision to inject a #PF can be made when
>> > handling an EPT violation - the accessed page needs not be related in
>> > any way with the page for which we decide to inject the #PF. For
>> > example, we intercept writes in a list that describes the loaded
>> > module. Whenever a new module is loaded, an entry would be inserted
>> > into that list, and that would generate an EPT write violation. Now,
>> > the introspection logic will be able to analyze what module was loaded
>> > and where, and it may find out that the module headers (which are
>> > needed by the protection logic) are not present in memory - therefore,
>> > it would inject a #PF in order to force the OS to swap in said
>> > headers. On the other hand, the HVI logic may also decide that it
>> > doesn't need to watch for modules loading anymore (for example, all the
>> interesting modules were loaded), so it will remove the write hook from the
>> list of loaded modules.
>> > These two (injection of the #PF and the removal of the EPT write
>> > protection) would be done in the same event handler, so we can't rely
>> > on the event being re-generated in this case. Hopefully this example
>> makes it more clear.
>> 
>> If the decision whether further events are needed depends on data in a
>> page not present in memory, how can that decision be taken before the
>> injected #PF has actually been handled? I'm still not seeing a flow of events
>> where there is a problem. Furthermore, I don't think it would do much harm
>> if you kept the watch in place slightly longer?
> 
> The decision whether further events are needed or not is NOT made based on 
> the contents of the missing page. Let us assume we have the MODULE structure, 
> that contains a "name" and an "address". The MODULE is inserted in the 
> modules list via a write, which triggers an EPT violation, which is handled 
> by HVI. The HVI sees that "name" is the module it was waiting for (for 
> example, ntdll, kernel32, or whatever), and decides that it doesn't want to 
> intercept other modules being loaded, so it removes the write hook from the 
> list. Furthermore, it sees that "address" points to a swapped-out page, so it 
> injects a #PF, to swap it in. 

So what's the #PF needed for then, if the introspection engine doesn't
need looking at the page? Once again - I think it would have helped
quite a bit if a _complete_ picture had been drawn from the very
beginning of this thread.

Jan


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