On Friday, 24.05.2019 at 12:26, Sean Christopherson wrote: > 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). This is a good point, and it had slipped my mind. Thanks for bringing it up. So it looks like the correct way forward would be to use individual memslots for the different Solo5 guest regions rather than mprotect() from the host, i.e. splitting the protection bits at all the different layers (host, EPT/TDP, guest). This does change our architecture somewhat, I'll think about how it could work and come back to this, am in the middle of some feature work right now. Thanks for the feedback.
