Re: Interaction between host-side mprotect() and KVM MMU

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

On Thu, May 23, 2019 at 11:27:03AM +0200, Martin Lucina wrote:
> On Tuesday, 21.05.2019 at 07:02, Sean Christopherson wrote:
> > Not without modifying KVM and the kernel (if you want to do it through
> > mprotect()).
> 
> Hooking up the full EPT protection bits available to KVM via mprotect()
> would be the best solution for us, and could also give us the ability to
> have execute-only pages on x86, which is a nice defence against ROP attacks
> in the guest. However, I can see now that this is not a trivial
> undertaking, especially across the various MMU models (tdp, softmmu) and
> architectures dealt with by the core KVM code.

Belated thought on this...

Propagating PROT_EXEC from the host's VMAs to the EPT tables would require
having *guest* memory mapped with PROT_EXEC in the host.  This is a
non-starter for traditional virtualization as it would all but require the
hypervisor to have RWX pages.

For the Solo5 case, since the guest is untrusted, mapping its code as
executable in the host seems almost as bad from a security perspective.

So yeah, mprotect() might be convenient, but adding a KVM_MEM_NOEXEC
flag to KVM_SET_USER_MEMORY_REGION would be more secure (and probably
easier to implement in KVM).