On Mon, 2020-12-14 at 23:22 +0100, Vitaly Kuznetsov wrote: > > Can you define kvm_hv_msr_enabled()? > > > > Note kvm_hv_hypercall_enabled() is based on a value that gets written > > through the MSR, so it can't be that. > > When Hyper-V emulation appeared in KVM we (unfortunately) didn't add a > capability to globaly enable and disable it so to be backwards > compatible we'll have to define kvm_emulating_hyperv() as 'true' for > now as that's how KVM behaves. This, however, doesn't mean we can't add > e.g. a module parameter to disable Hyper-V emulation. Also, we can > probably check guest CPUIDs and if Hyper-V's signature wasn't set we can > return 'false'. > > <rant> > Having Hyper-V emulation in KVM 'always enabled' may not be a big deal > from functional point of view but may not be ideal from security > standpoint as bugs in arch/x86/kvm/hyperv.c become exploitable even from > Linux guests. > </rant> Indeed. And yet it can coexist with Xen support too, so it isn't even as simple as turning it off when Xen is enabled. Which is why I ended up just using Joao's patch unchanged. Short of going back in time to make Hyper-V support conditional when it was first introduced, I couldn't see a better answer. And regardless of the Hyper-V mess, what this patch does for Xen is precisely what you suggest: handle it first, before the switch(), *if* the Xen MSR is enabled.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
