2017-08-16 19:19+0200, Paolo Bonzini: > On 16/08/2017 18:50, Michael S. Tsirkin wrote: >> On Wed, Aug 16, 2017 at 03:30:31PM +0200, Paolo Bonzini wrote: >>> While you can filter out instruction fetches, that's not enough. A data >>> read could happen because someone pointed the IDT to MMIO area, and who >>> knows what the VM-exit instruction length points to in that case. >> >> Thinking more about it, I don't really see how anything >> legal guest might be doing with virtio would trigger anything >> but a fault after decoding the instruction. How does >> skipping instruction even make sense in the example you give? > > There's no such thing as a legal guest. Anything that the hypervisor > does, that differs from real hardware, is a possible escalation path. > > This in fact makes me doubt the EMULTYPE_SKIP patch too.
The main hack is that we expect EPT misconfig within a given range to be a MMIO NULL write. I think it is fine -- EMULTYPE_SKIP is a common path that should have well tested error paths and, IIUC, virtio doesn't allow any other access, so it is a problem of the guest if a buggy/malicious application can access virtio memory. >>>>> Plus of course it wouldn't be guaranteed to work on nested. >>>> >>>> Not sure I got this one. >>> >>> Not all nested hypervisors are setting the VM-exit instruction length >>> field on EPT violations, since it's documented not to be set. >> >> So that's probably the real issue - nested virt which has to do it >> in software at extra cost. We already limit this to intel processors, Hm, there is no reason to exclude SVM. >> how about we blacklist nested virt for this optimization? Not every hypervisor can be easily detected ... KVM uses standard features and SDM clearly says that the instruction length field is undefined. We only lose performance if we decode the instruction, but piling workarounds creates unexpected corner cases. I still don't see acceptable alternatives to Paolo's solution.
