> Am 20.05.2019 um 11:33 schrieb Sean Christopherson <sean.j.christopherson@xxxxxxxxx>: > >> 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. I see - I must have forgotten about some change I did on my playground setup then. Either way, you want a direct deflection path. You can not guarantee that a page is always present on an overcommitted system. Alex
