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 see two solutions: (a) have the in-guest agent generate a VMCALL that KVM will interpret as EPT-violation and call the default page fault handler; (b) populate the EPT completely before entering the guest; The first one requires adding dedicated code for KVM in the agent used for handling #VE events, something we are trying to avoid. The second one has implications we can't fully see, besides migration with which we don't interact (VMI is designed to be disabled before migration starts, implicitly #VE too). I would appreciate any opinion / suggestion you have on a proper approach to this issue. Regards, -- Mihai Donțu
