Demystifying Microcode Updates for Intel and AMD Processors

[SteveMat]

Hello, my name is Steve Mathias, Microsoft Premier Field Engineer (PFE) and I wanted to spend a moment to discuss the “mechanics” of the Intel Microcode Updates that you may see coming down from Microsoft Update or the Windows Catalog.  The security implications of why you should update the microcode on your processors are already covered in the below documentation from us and our partners (Spectre/SBB/etc.):

https://support.microsoft.com/en-us/help/4093836/summary-of-intel-microcode-updates

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html

https://www.amd.com/en/corporate/product-security

The purpose of this blog is to help answer why Microsoft is collaborating with our partners Intel and AMD on these microcode updates and a little background on how these updates work.  To start the discussion, we need to lay down a key fact:

• When processors are manufactured, they have a baseline microcode baked into their ROM.  This microcode is immutable and cannot be changed after the processor is built.

Modern processors do have the ability at initialization to apply volatile updates to move the processor to a newer microcode level.  However, as soon as the processor is rebooted, it reverts back to the microcode baked into their ROM.  These volatile updates can be applied to the processor one of two ways – System Firmware/BIOS via OEM and by the Operating System (OS).  However, as stated earlier, neither is updating the microcode in the processors ROM.  If you were to remove the processor from one computer and install in a computer with an older System Firmware/BIOS and an un-updated OS, you will be back to being vulnerable.

Couple common questions:

• Why is Microsoft collaborating with Intel and AMD and publishing Microcode Updates via Microsoft Update?

The answer is simply that Windows offers the broadest coverage and quickest turnaround time to address these vulnerabilities.  Microcode updates delivered via the Windows OS are not new; as far back as 2007 some updates were made available to address performance and reliability concerns.

• Can I skip taking updates delivered via Windows and only take updates from my OEM via System Firmware/BIOS Update?

Technically speaking you could but as mentioned earlier, often Microsoft Update may have the microcode updates to address issues much sooner.  Work with your OEM to help make this decision or simply take the updates from Microsoft Update.

• Is there a problem if I update my System Firmware/BIOS with one version of a microcode update and allow Windows to install a different version of a microcode update?

When the processor boots, it has versioning to make sure it is utilizing the latest microcode updates regardless of where it may be coming from.  So, installing System Firmware/BIOS updates and microcode updates from Microsoft Update is perfectly acceptable.  It is possible that the OEM updates the microcode to one level and the OS updates the microcode to an even higher level during the same boot.

• In Windows, how are microcode updates delivered to the processor?

Microcode updates install like any other update.  They can be installed from Microsoft Update, WSUS, SCCM or manually installed if downloaded from the Catalog.  The key difference is that the payload of the hotfix is primarily one of two files:

mcupdate_GenuineIntel.dll – Intel

mcupdate_AuthenticAMD.dll - AMD

These files contain the updated microcode and Windows automatically loads these via OS Loader to patch the microcode on the boot strap processor.  This payload is then passed to additional processors as they startup as well the Hyper-V hypervisor if enabled.

Hopefully this information will help demystify what these microcode updates are and allow you to confidently install these updates proactively.

[Bronson_Magnan]

Steve, should virtual machines be seeing these updates as available if their hyper-visor is patched? Also, what "category" would these show up under in WSUS?

[SteveMat]

Hyper-V virtual machines will be offered the microcode updates from Microsoft Update (assuming the CPUID matches) however the host is what really needs to be updated as it's payload is passed through to the virtual machines.  From a Windows Server 2016 Virtual Machine:

They are classified as "Updates" in WSUS and on Microsoft Update:

[EERMX]

@SteveMat , is there a specific update order when it comes to updating Hyper-V servers and virtual machines running on those servers?

In other words, do we have to update the hypervisors first and then the virtual machines? Or virtual machines first and then the hypervisors? Or does the order not matter?

[SteveMat]

Updating the Hyper-V Host is what is important as the microcode is passed to the virtual machines.  So with that said, it would be prudent to update the Hyper-V Host first as that is the priority.

[EERMX]

Thanks @SteveMat. In that case, does updating the virtual machines achieve anything? Is it even needed?

[SteveMat]

When the Hyper-V Host has the microcode updated, it presents the updated microcode to the guest virtual machines so they are already updated when they start.  Installing the microcode updates to the virtual machines should be done for consistency.

[EERMX]

Thanks for the reply @SteveMat. What happens then in the case when the virtual machines are updated with the microcode updates and they move between hyper-v hosts that are running different CPUs, some of which have no applicable microcode updates?

For example, take a two node 2019 Hyper-V cluster: one with a E5-2680 CPU which has a microcode update available and it's installed, and the other node with a Gold 6248 CPU which has no applicable microcode updates available. What happens if a VM with updated microcode that was on the 2680 is moved to the 6248?

Assuming the CPU compatibility option is set.