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. Or are you referring to the MMIO misconfiguration trick that KVM does? > 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; ... in that case yes, I would like to see a VMCALL to just bounce that trap back into KVM. > (b) populate the EPT completely before entering the guest; ... because this will not help you in any way :). Alex > > 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, >
