Different Microcode update methods

Hello everyone,

I’ve read about different ways to update the CPU microcode but have not read one good explanation/comparison about the difference between them:

- Modifying BIOS/UEFI with new microcode
the motherboard updates the microcode on boot?

- “Intel Microcode Boot Loader” (based on BITS - Intel BIOS Implementation Test Suite)
the motherboard boots to an external USB drive, which updates the microcode on the CPU and then proceeds to boot Windows?

- Microsoft Windows Updates
Windows loads the microcode (stored on “C:\Windows\System32\mcupdate_GenuineIntel.dll”) before the Windows kernel?

- VMware CPU Microcode Update Driver
Windows loads the microcode after the Windows kernel?


Where is the microcode stored - on the CPU itself or on the motherboard?

The thing I don’t really understand yet is: The only way for me to update the microcode “on hardware” is through BIOS/UEFI modding and updating?
In other words, if I update my microcode through Windows Update (or the VMWare driver) and then boot my computer from another Windows installation, I will be using the old microcode that shipped with my CPU?
And in between the pressing of the power button and the loading of the Windows kernel, my computer would be vulnerable to security exploits?


Thanks.

Modern CPUs need an externally supplied microcode to function - the moment they get electricity they work in a minimal function set, just enough to start BIOS/UEFI. And one of the first things that BIOS/UEFI will do is load the CPU with the needed microcode. BIOS/UEFI must always provide a microcode, without that the CPU is unable to work on any usable level. After this is done the microcode can be updated by software at any time after the machine has booted. The problem is that when you update the microcode at a random time the OS has no knowledge that the microcode has been updated and maybe new commands have been enabled. This is why Windows official microcode DLL (the one in Windows Update) or Linux loads the microcode update at earliest possible moment the OS is booting. Because the OS will evaluate the features of the CPU after new microcode has been loaded on. This is where VMware DLL is basicaly useless for security workarounds (for SPECTRE/MELTDOWN etc) - it is loaded AFTER Windows has decided what worakounds to use based on the capabilites that the CPU is reporting. BITS is just a bootloader that does one specific task - update microcode and procede to booting an OS.

The moment you power off or reboot the machine the microcode is gone and the same thing happens again - BIOS/UEFI will load the first microcode to the CPU. So technically if your BIOS/UEFI has an old microcode then whatever is done before the OS has updated the microcode the CPU is "vulnerable". But if any "intruder" has access to the boot process of your machine you have much bigger worries.

Thanks for the explanation!
I’ll be sure to modify and update the BIOS/UEFI in my company’s computers when performing maintenance and before creating a fresh Windows installation, that way I will not have to worry wether the OS was updates to provide the latest microcodes or not.

Currently I’m using the Windows 10 2004 (20H1) RTM build from the ISO provided on the Windows Insider website.
I suppose “out of the box” it already includes the latest microcodes, without having to download anything from Windows Updates?