|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v13] x86/emulate: Send vm_event from emulate
On 23.09.2019 16:05, Paul Durrant wrote: >> -----Original Message----- >> From: Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx> >> Sent: 23 September 2019 13:06 >> To: xen-devel@xxxxxxxxxxxxxxxxxxxx >> Cc: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; jbeulich@xxxxxxxx; Andrew Cooper >> <Andrew.Cooper3@xxxxxxxxxx>; wl@xxxxxxx; Roger Pau Monne >> <roger.pau@xxxxxxxxxx>; Razvan COJOCARU >> <rcojocaru@xxxxxxxxxxxxxxx>; tamas@xxxxxxxxxxxxx; Alexandru Stefan ISAILA >> <aisaila@xxxxxxxxxxxxxxx>; >> Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>; George Dunlap >> <George.Dunlap@xxxxxxxxxx> >> Subject: [PATCH v13] x86/emulate: Send vm_event from emulate >> >> A/D bit writes (on page walks) can be considered benign by an introspection >> agent, so receiving vm_events for them is a pessimization. We try here to >> optimize by filtering these events out. >> Currently, we are 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. >> The solution 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 at RIP. When we send out a vm_event, we don't want the >> emulation >> to complete, since in that case we won't be able to veto whatever it is >> doing. >> That would mean that we can't actually prevent any malicious activity, >> instead >> we'd only be able to report on it. >> When we see a "send-vm_event" case while emulating, we need to first send the >> event out and then suspend the emulation (return X86EMUL_RETRY). >> After the emulation stops we'll call 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. >> >> A common example is if the hardware exits because of an EPT fault caused by a >> page walk, p2m_mem_access_check() decides if it is going to send a vm_event. >> If the vm_event was sent and it would be treated so it runs the instruction >> at RIP, that instruction might also hit a protected page and provoke a >> vm_event. >> >> Now if npfec.kind == npfec_kind_in_gpt and >> d->arch.monitor.inguest_pagefault_disabled >> is true then we are in the page walk case and we can do this emulation >> optimization >> and emulate the page walk while ignoring the EPT, but don't ignore the EPT >> for the >> emulation of the actual instruction. >> >> In the first case we would have 2 EPT events, in the second case we would >> have >> 1 EPT event if the instruction at the RIP triggers an EPT event. >> >> We use hvmemul_map_linear_addr() to intercept write access and >> __hvm_copy() to intercept exec, read and write access. >> >> A new return type was added, HVMTRANS_need_retry, in order to have all >> the places that consume HVMTRANS* return X86EMUL_RETRY. >> >> hvm_emulate_send_vm_event() can return false if there was no violation, >> if there was an error from monitor_traps() or p2m_get_mem_access(). >> -ESRCH from p2m_get_mem_access() is treated as restricted access. >> >> NOTE: hvm_emulate_send_vm_event() assumes the caller will enable/disable >> arch.vm_event->send_event >> >> Signed-off-by: Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx> >> > > emulate parts... > > Acked-by: Paul Durrant <paul@xxxxxxx> > Thanks for the ack. Alex _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |