Messages in this thread | | | Date | Thu, 2 Jul 2020 11:42:16 -0700 | From | Sean Christopherson <> | Subject | Re: [PATCH RFC 0/7] CPU feature evaluation after microcode late loading |
| |
On Thu, Jul 02, 2020 at 06:18:20PM +0300, Mihai Carabas wrote: > This RFC patch set aims to provide the ability to re-evaluate all CPU > features and take proper bug mitigation in place after a microcode > late loading. > > This was debated last year and this patch set implements a subset of > point #2 from Thomas Gleixner's idea: > https://lore.kernel.org/lkml/alpine.DEB.2.21.1909062237580.1902@nanos.tec.linutronix.de/ > > Point #1 was sent as an RFC some time ago > (https://lkml.org/lkml/2020/4/27/214), but after a discussion with CPU > vendors (Intel), the metadata file is not easily buildable at this > moment so we could not advance with it more. Without #1, I know it is > unlikely to embrace the feature re-evaluation. > > Patches from 1 to 4 bring in changes for functions/variables in order to be > able to use them at runtime. > > Patch 5 re-evaluates CPU features, patch 6 is re-probing bugs and patch 7 > deals with speculation blacklist CPUs/microcode versions.
This misses critical functionality in KVM. KVM snapshots boot_cpu_data at module load time (and does further modifications) for ongoing reuse in filtering what features are advertised to the userspace VMM. See kvm_set_cpu_caps() for details.
Even if you found a way to reference kvm_cpu_caps, that still leaves the problem of existing guests having been created with stale data. Oh, and KVM also needs to properly handle MSR_IA32_TSX_CTRL.
Rather than forcefully tearing down guests, what about adding a way to block updates, e.g. KVM would block updates on module load and unblock on module exit. That puts the onus of coordinating updates on the orchestration layer where it belongs.
KVM aside, it wouldn't surprise in the least if there is other code in the kernel that captures bug state locally. This series feels like it needs a fair bit of infrastructure to either detect conflicting usage at build time or actively prevent consuming stale state at runtime.
There's also the problem of the flags being exposed to userspace via /proc/cpuinfo, though I suppose that's userspace's problem to not shoot itself in the foot.
| |