Updating AMD microcode from Qubes OS

This guide will show you how to extract AMD microcode from mainboard firmware updates, and convert it into a binary format that can be loaded by Xen.

Using UEFI firmware updates is recommended when updating AMD microcode, because it includes OEM updates and AGESA updates. Patching the microcode is a temporary solution, that can be used until a stable UEFI firmware update has been released.

Qubes OS includes the amd-ucode-firmware package, which contains microcode released by AMD, but it is primarily used to deploy microcode for AMD’s enterprise line of CPUs.

It is possible to dump the microcode from consumer mainboard firmware updates, and have Xen load the dump in the same way microcode from amd-ucode-firmware is loaded. The system will first load the microcode from the UEFI firmware, Xen then checks if the OS provided microcode is newer, and only use it if it is an update.

AMD CPU microcode signature verification vulnerability

A vulnerability was found in the method used by AMD to sign microcode, which could allow an attacker to modify microcode.
The issue was fixed in AGESA 1.2.0.3C for Zen 5 and 4, and 1.2.0.E for prior versions, make sure you are using UEFI firmware with an updated version of the AGESA.
The security update changed how the microcode is verified, systems without the update are not able to load microcode released after the AGESA update.

CPUID and current microcode version

You need to know your CPUID to find the correct microcode dump, and it can be useful to know which version of the microcode is currently being used.
In dom0, you can use cat /proc/cpuinfo | grep microcode to get the version of the currently used microcode.
On my system the CPUID is the first 4 bytes of the ID, in reverse order, but I don’t know if this is true for all CPUs
In dom0, you can use sudo dmidecode -t 4 | grep ID to get the ID, which should give an output similar to ID: 40 0F B4 00 FF FF FF FF, where the CPUID is 0x00B40F40

Extracting the microcode

Clone the MCExtractor repo GitHub - platomav/MCExtractor: Intel, AMD, VIA & Freescale Microcode Extraction Tool
MCE has a few dependencies that can be installed in venv with pip.
Download an OEM firmware update, it does not have to be for your mainboard, it just has to be for a mainboard that supports your CPU.
Use the MCE.py script on the firmware update, to extract the microcode. It will compare the microcode to its database, and tell you if the microcode matches the latest known version for the CPU.

$ python MCE.py <path to firmware>

The microcode dump will be in the Extracted directory. The format for the filename is CPUID_VERSION_DATA_CHECKSUM, find the file that match your CPUID, if the CPUID is 0x00B40F40 there should be a file that starts with cpu00B40F40.

Generate the microcode container

Clone the amd-ucodegen repo GitHub - AndyLavr/amd-ucodegen: Tool to generate AMD microcode files
Make the c file, using standard build tools, and use amd-ucodegen to make a microcode container.

$ ./amd-ucodegen <path to file extracted with MCE>

It should give you a file with a filename similar to microcode_and_famXXX.bin, where XXX is the ID for your CPU family.

Install the microcode

In dom0, check if there exist a file in /lib/firmware/amd-ucode, with the same name as the file generated with amd-ucodegen. If it exists, make a backup before overwriting it with the new microcode.

Copy the file you generated with amd-ucodegen to /lib/firmware/amd-ucode, use the command sudo dracut -f, and reboot the system.

After the system has reboot, you can use xl dmesg to check if Xen is loading the microcode. If you are getting an error about the digits-check failing, you need to add digest-check=off to the Xen ucode parameter.

When everything is working, xl dmesg should look similar to this:

(XEN) Microcode patch additional digest checks disabled<2>BSP microcode revision: 0x0b404022
(XEN) microcode: CPU0 updated from revision 0xb404022 to 0xb404023, date = 2024-09-20
6 Likes

Is there a good rule of thumb for a motherboard manufacturer that is timely with bios updates to pull the microcode from ? Or a model that gets updates quickly ?

1 Like

I would just use the OEM firmware when possible, but it shouldn’t matter as long as you get the firmware for a motherboard that supports the same CPU model.

MCExtractor maintains a community repository of microcode versions, you can use it to see if your OEM is using the latest version.

https://github.com/platomav/CPUMicrocodes/tree/master/AMD

The microcode from their repo is the microcode extracted from OEM firmware, but it could be a security risk to use it, if someone discovers a new signing exploit.

3 Likes

Nevermind: I can see the date on the GitHub matches the MSI bios date (despite the upload being later)

Ok, forgive me for being pedantic

What do you do currently ?

I see MSI has a bios update from 10-21-25 (approx 5 weeks ago) but the CPUMicrocodes GitHub has a BIN for your CPU from 3 weeks ago.

I assume that the GitHub is a newer version (esp since the MSI notes don’t mention any security updates or anything for 9000 series)

So how do you get a bios update to extract the newest microcode ?

1 Like

I noticed that the CPUID is included in

xl dmesg | grep raw

If you don’t want to reverse the bytes


FYI On my Intel xeon CPU it seems impossible to get the version info in /proc/cpu_info to change/iterate

I have bios from 18 months ago, the GitHub link says my CPU has a newer version (11 months ago). Updating dom0 doesn’t change it. Neither do updates on a plain Fedora install (not qubes). I also updated the bios to latest from a month ago and the version doesn’t change. Perhaps just an issue with Xeon

EDIT: On further research, I think the entry for my CPU at that github link is erroneous. Intel’s GitHub doesn’t show that version and I’ve tried an ubuntu install to see if a new version pops up (it doesn’t)

EDIT2: Actually I found the version that platomav GitHub lists, on a enterprise motherboard so his info is legit. I copied it to dom0 (and changed the name to Intel’s version) and xl dmesg correctly showed the new version :fire: I also found this interesting

I can delete this post out if you don’t want it cluttering your guide

2 Likes

Intel publishes their microcode updates on GitHub, and they have rich descriptions of what the updates contain.

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases

On the consumer level, there is no denying that Intel is miles ahead of AMD when it comes to microcode updates.

2 Likes

What are you thoughts on just using the platomav provided extractions ? He says it’s ok since they are signed (as long as your agesa is updated). Usually I wouldn’t but it’s quite a bit of detective work to find a mb update with the newest microcode

Any thoughts on arch wiki opinion on late loading microcode updates ? Perhaps it is an older issue (or qubes mitigates it) because I did:

cat /proc/sys/kernel/tainted

and it returned 0 (not tainted) even though I late loaded microcode

https://wiki.archlinux.org/title/Microcode
section 2.2

The extraction tool is helpful for analyzing a mb update for whether it has a new microcode version. I have foolishly loaded bios update betas due to confusing notes about having a security update only to find that there is no microcode update and now I’m running a potentially unstable or buggy bios. Just for that reason the tool is very useful

1 Like

I think it’s okay to use the updates from Platomav, but make sure your firmware (AGESA) has the signing bug patch.

Xen can extract the microcode from Linux initrd, that is how the microcode from dom0 is loading onto the CPU when the system boots.

As far as I understand, dom0 is just a VM and it doesn’t have access to the physical CPU, and Linux in dom0 can’t late load the microcode. If you actually wanted to load microcode after the system has booted, you need to use the xen-ucode tool. You can also use the ucode parameter to load microcode directly from the boot parameters, the default ucode=scan just tells ucode to scan the Linux boot image for the microcode.

2 Likes

Thanks for the explanation. I saw the /lib/firmware/ folder and assumed it was late loading. I didn’t realize that folder was being used by dracut to generate the initrd image that is used earlier in the bootloader process.

2 Likes

Any thoughts on this vulnerability ? I suppose it is patched in the Nov 2025 version

Does the fact that Xen doesn’t mention it yet mean that it doesn’t effect xen systems ?

https://xenbits.xen.org/xsa/

I don’t think it’s something that Xen can fix.

The fix has been released by AMD. Until the microcode gets included in the linux-firmware package, the feature has been disabled by the kernel.

Journal should show the message:
RDSEED32 is broken. Disabling the corresponding CPUID bit.

1 Like

Thanks for all your advice and explanations.

I’m successfully updated to latest version 4035 through the qubes dom0 update. As your guide noted, the digest check was blocking the update (no digest found).

The parameter in grub for ucode=scan,digest-check=off was a little tricky… that dang comma placement caused a lot of confusion

And yes, I can see the warning about RDSEED bit now.

1 Like