2018-02-26 18:49 GMT+08:00 Borislav Petkov <b...@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
