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

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

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@bitdefender.com> 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. We're not after anything out of the 
ordinary or fitting a niche case - we just want to filter out vm_events 
caused by page walks in a manner that remains safe for the guest OS user.


Thanks,
Razvan

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