On Mon, May 20, 2019 at 11:10:51AM -0700, Alexander Graf wrote: > On 20.05.19 08:48, Mihai Donțu wrote: > > Hi Paolo, > > > > We are looking at adding #VE support to the VMI subsystem we are > > working on. Its purpose is to suppress VMEXIT-s caused by the page > > table walker when the guest page tables are write-protected. A very > > small in-guest agent (protected by the hypervisor) will receive the EPT > > violation events, handle PT-walk writes and turn the rest into VMCALL- > > s. > > > > A brief presentation of similar work on Xen can be found here: > > https://www.slideshare.net/xen_com_mgr/xpdss17-hypervisorbased-security-bringing-virtualized-exceptions-into-the-game-mihai-dontu-bitdefender > > > > There is a bit of an issue with using #VE on KVM, though: because the > > EPT is built on-the-fly (as the guest runs), when we enable #VE in > > VMCS, all EPT violations become virtualized, because all EPTE-s have > > bit 63 zero (0: convert to #VE, 1: generate VMEXIT). At the moment, I > > Are you 100% sure? Last time I played with #VE, it only triggered on > misconfigurations/permission checks (lack of R/W/X, but P=1), not on P=0 > pages. #VEs trigger on RWX=0, but not misconfigurations, i.e. any and all EPT_VIOLATION exits (reason 48) are convertible, and EPT_MISCONFIG exits (reason 49) are never convertible. The reasoning behind the logic is that an EPT_MISCONFIG is the result of a VMM bug (or in KVM's case, MMIO trickery), whereas a RWX=0 EPT_VIOLATION could be a malicious entity in the guest probing non-existent pages or pages it doesn't have access to.
