Messages in this thread | | | From | Wanpeng Li <> | Date | Mon, 26 Feb 2018 19:02:29 +0800 | Subject | Re: [PATCH] KVM: X86: Allow userspace to define the microcode version |
| |
2018-02-26 18:49 GMT+08:00 Borislav Petkov <bp@alien8.de>: > On Mon, Feb 26, 2018 at 06:06:42PM +0800, Wanpeng Li wrote: >> I think it is the host admin(e.g. cloud provider)'s responsibility to >> set an expected microcode revision. > > + vcpu->arch.microcode_version = 0x1; > > That already looks pretty arbitrary and non-sensical to me.
This is the original kvm implementation before the patch.
> >>In addition, the non-sensical value which is written by the guest will >>not reflect to guest-visible microcode revision and just be ignored in >>this implementation. > > Huh? How so? > > So a guest will have *two* microcode revisions - both of which are most > likely wrong?!
Just one revision.
> > This whole thing sounds like the wrong approach to me. > >> Linux (among the others) has checks to make sure that certain features >> aren't enabled on a certain family/model/stepping if the microcode version >> isn't greater than or equal to a known good version. > > It sounds to me like the proper fix is to make the kernel *not* look at > microcode revisions when running virtualized. The same way we're not > loading microcode in a guest: > > if (native_cpuid_ecx(1) & BIT(31)) > > Letting userspace control the microcode revision number is revision > number management SNAFU waiting to happen IMO.
https://lkml.org/lkml/2017/12/9/29 The original discussion explain in more details.
Regards, Wanpeng Li
| |