Re: #VE support for VMI

[Sean Christopherson <sean.j.christopherson@intel.com>]

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.