Re: [Xen-devel] xc_hvm_inject_trap() races

[Andrei Vlad LUTAS <vlutas@xxxxxxxxxxxxxxx>]

-----Original Message-----
From: Jan Beulich [mailto:jbeulich@xxxxxxxx]
Sent: 1 November, 2016 18:40
To: rcojocaru@xxxxxxxxxxxxxxx; Andrei Vlad LUTAS <vlutas@xxxxxxxxxxxxxxx>
Cc: andrew.cooper3@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx; 
tamas@xxxxxxxxxxxxx
Subject: Re: RE: [Xen-devel] xc_hvm_inject_trap() races

>>> Andrei Vlad LUTAS <vlutas@xxxxxxxxxxxxxxx> 11/01/16 5:13 PM >>>

>First of all, please don't top post.

>>First of all, to answer your original question: the injection decision
>>is made when the introspection logic needs to inspect a page that is
>>not present in the physical memory. We don't really care if the current
>>instruction triggers multiple faults or not (and here I'm not sure what
>>you mean by that - multiple exceptions, or multiple EPT violations -
>>but the answer is still the same), and removing the page restrictions
>>after the #PF injection is introspection specific logic - the address
>>for which we inject the #PF doesn't have to be related in any way to the 
>>current instruction.

>Ah, that's this no-architectural behavior again.

I don't think the HVI #PF injection internals or how the #PF is handled by the 
OS are relevant here. We are using an existing API that seems to not work quite 
correct under certain circumstances and we were curious if any of you can shed 
some light in this regard, and maybe point us to the right direction for 
cooking up a fix.

>What if the OS doesn't fully carry out the page-in, relying on the #PF to 
>retrigger once the insn for which it got reported has been restarted?

Can you be more specific?

> Or what if the page gets paged out again before the insn actually gets to 
> execute (e.g. because a re-schedule happened inside the guest on the way out 
> of the #PF handler)? All of this suggests that you really can't lift >any 
> restrictions _before_ seeing what you need to see.

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.

>>Assuming that we wouldn't remove the restrictions and we would rely on
>>re-generating the event - that is not acceptable: first of all because
>>the instruction would normally be emulated anyway before re-entering
>>the guest,

>How would that be a problem?

I thought it was obvious without further clarification: how can we expect the 
exact same event to be generated, if the instruction that triggered it in the 
first place was emulated or single stepped?

>>and secondly because that is not a normal CPU behavior

>This really is the main problem here, afaict.

Best regards,
Andrei.


________________________
This email was scanned by Bitdefender

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