Intel Making Improvements For CPU Microcode Updating Under Linux

Intel engineers are working on enhancing the x86_64 CPU microcode updating experience under Linux and in particular the work is ultimately around better supporting of late microcode loading on Linux for Intel systems with a primary focus on Intel servers / enterprise users.

Via tip.git's x86/microcode branch is an initial batch of x86 microcode handling improvements for the Linux kernel. The patches remove some useless mutexes, dropping some old debug code, and also make it now that CPU microcode loading support is no longer an option on x86-based systems but is always enabled. With any "reasonable configuration" needing microcode loading support on Intel and AMD systems, the option is now always enabled.

Those initial x86 microcode loading improvements at least are queued up in TIP and should be part of the upcoming Linux 6.6 cycle.

On top of this, Thomas Gleixner has been leading the work to improve late microcode loading on Intel Linux systems. He explained in this patch series:

"Late microcode loading is desired by enterprise users. Late loading is problematic as it requires detailed knowledge about the change and an analysis whether this change modifies something which is already in use by the kernel. Large enterprise customers have engineering teams and access to deep technical vendor support. The regular admin does not have such resources, so the kernel has always tainted the kernel after late loading.

Intel recently added a new previously reserved field to the microcode header which contains the minimal microcode revision which must be running on the CPU to make the load safe. This field is 0 in all older microcode revisions, which the kernel assumes to be unsafe. Minimal revision checking can be enforced via Kconfig or kernel command line. It then refuses to load an unsafe revision. The default loads unsafe revisions like before and taints the kernel. If a safe revision is loaded the kernel is not tainted.

But that does not solve all other known problems with late loading:

- Late loading on current Intel CPUs is unsafe vs. NMI when hyperthreading is enabled. If a NMI hits the secondary sibling while the primary loads the microcode, the machine can crash.

- Soft offline SMT siblings which are playing dead with MWAIT can cause damage too when the microcode update modifies MWAIT. That's a realistic scenario in the context of 'nosmt' mitigations. :(

Neither the core code nor the Intel specific code handles any of this at all.

While trying to implement this, I stumbled over disfunctional, horribly complex and redundant code, which I decided to clean up first so the new functionality can be added on a clean slate."

Late microcode loading on Linux is around allowing the CPU microcode to be updated when the system is already booted and running software, compared to loading microcode early during the boot time when the CPU cores are not busy. Late loading CPU microcode is useful particularly for hyperscalers and cloud service providers and other large organizations who want to quickly deploy new CPU microcode updates in the name of security but avoid system downtime. It's not clear yet if this improved Intel CPU microcode late-loading will be wrapped up in time for the v6.6 kernel but at least this improvement is in the works.