Re: [Xen-devel] [PATCH v5] x86/emulate: Send vm_event from emulate

[Jan Beulich <JBeulich@xxxxxxxx>]

On 01.07.2019 17:13, Razvan Cojocaru wrote:
> On 7/1/19 5:45 PM, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 01.07.2019 16:13, Jan Beulich wrote:
>>>>>> On 04.06.19 at 13:49, <aisaila@xxxxxxxxxxxxxxx> wrote:
>>>> This patch aims to have mem access vm events sent from the emulator.
>>>> This is useful where we want to only emulate a page walk without
>>>> checking the EPT, but we still want to check the EPT when emulating
>>>> the instruction that caused the page walk. In this case, the original
>>>> EPT fault is caused by the walk trying to set the accessed or dirty
>>>> bits, but executing the instruction itself might also cause an EPT
>>>> fault if permitted to run, and this second fault should not be lost.
>>>
>>> I'm afraid I still can't translate this into what exactly is wanted and
>>> why. While typically we don't use examples to demonstrate that is
>>> wanted in commit messages, I think this is a rather good candidate
>>> for actually using such an approach. This may then ...
>>>
>>>> We use hvmemul_map_linear_addr() to intercept r/w access and
>>>> __hvm_copy() to intercept exec access.
>>>>
>>>> First we try to send a vm event and if the event is sent then emulation
>>>> returns X86EMUL_RETRY in order to stop emulation on instructions that
>>>> use access protected pages. If the event is not sent then the
>>>> emulation goes on as expected.
>>>
>>> ... also help understanding this part, which I continue to be confused
>>> by, too.
> 
> Simply put, the introspection agent wants to treat all A/D bit writes as 
> benign. Receiving vm_events about them is a big pessimization, and we want to 
> optimize.
> 
> We'd like to filter these events out.
> 
> To this end, we're currently (in the present incarnation of the Xen code) 
> fully emulating the instruction at RIP when the hardware sees an EPT fault 
> with npfec.kind != npfec_kind_with_gla. This is, however, incorrect, because 
> the instruction at RIP might legitimately cause an EPT fault of its own 
> (while accessing a _different_ page from the original one, where A/D were 
> set).
> 
> We've tried to solve this by actually writing the A/D bits and returning from 
> p2m_mem_access_check(), however that has led to a slightly philosophical 
> discussion about the proper way to achieve our goals while taking into 
> account speculative setting of these bits. The issues raised have not been 
> satisfactorily answered in an authoritative manner to this day.
> 
> So the only option we seem to have left at this point is to perform the whole 
> emulation, _while_ ignoring EPT restrictions for the walk part, and taking 
> them into account for the "actual" emulating of the instruction @ RIP.
> 
> If we're sending out a vm_event, then we don't want the emulation to complete 
> - since in that case we won't be able to veto whatever is doing. That would 
> mean that we can't actually prevent any malicious activity that happens here, 
> instead we'd only be able to report on it.
> 
> So when we see a "send-vm_event" case while emulating, we need to do two 
> things:
> 
> 1. send the event out;
> 2. _don't_ complete the emulation (return X86EMUL_RETRY).
> 
> When 2. happens, we'll hit hvm_vm_event_do_resume() again _after_ the 
> introspection agent treats the event and resumes the guest. There, the 
> instruction at RIP will be fully emulated (with the EPT ignored) if the 
> introspection application allows it, and the guest will continue to run past 
> the instruction.
> 
> That's our plan, anyway. Hopefully we're not going in a wrong direction about 
> it (all help is very much appreciated).
> 
> I hope this has made thing clearer.

I think so, yes, and I'm getting the impression that in reply to an
earlier version you've already once explained this. The thing is -
the explanation needs to come _with_ the patch, not _after_ it.

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