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).
