That's an odd sort of mitigation. I don't really want my BIOS^WUEFI firmware booting up my OS in a VM. I want to be able to use the VMX extensions myself with full performance, which isn't going to work that well if I'm already stuck in a VM.
I thought one of the features of hardware virtualization support was to mask the fact that you are being virtualized, in which case nesting would be a requirement?
Everything that supports VT-x at all supports nested virtualization -- the outermost hypervisor (called L0 usually) simply emulates the VT-x instructions use by its guest (called L1). The guest's guest is called L2, and L0 switches back and forth between running L1 and L2 as needed.
The problem is that this is extremely slow. Haswell's shadow VMCS makes it less slow, but I doubt it performs particularly well. Another downside is that the CPU only supports two levels of page tables, so it gets awkward to make everything work securely and correctly without emulating a level of page tables as well.
> seems to indicate it does for Haswell and above.
and the exploit affects CPUs below sandy bridge, so that's of no use to the affected users if they want to use a virtualization solution inside their main OS (instead of cooperating with the underlying hypervisor)
> I thought one of the features of hardware virtualization support was to mask the fact that you are being virtualized
You could simply have a virtual CPU that does not support virtualization.
Or you could trap the offending instructions and emulate it in software. But that would come at a performance penalty that GP wants to avoid.
I don't think it would matter. KVM wouldn't move the real APIC -- it would just move the fake APIC it exposes to the guest. SMM doesn't run in guest mode, so SMM code wouldn't see the fake APIC.
(If KVM allowed moving the APIC, then you could use this to escalate privileges from guest kernel mode to /guest/ SMM, and KVM is adding guest SMM soon, but that's a much less interesting attack IMO.)
