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, <aisa...@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
