Intel and AMD Microcode and Properly Updating Microcode in Linux

1. Introduction

Microcode lives inside a Central Processing Unit (CPU). Specifically, AMD and Intel microcode is code within an AMD or Intel x86 processor that handles some aspects of its functionality. The microarchitecture of modern processors enables changes to this microcode through the operating system (OS) or machine firmware such as the Basic Input/Output System (BIOS) and Unified Extensible Firmware Inteface (UEFI).

In this tutorial, we understand what processor microcode is and how to update it on a Linux system. First, we define the concept of microcode in terms of two main processor manufacturers. After that, we go over ways to check the current processor information and microcode version. Next, we discuss native microcode packages and how to use them for microcode updates. Finally, we manually download, check, and install microcode for both processor manufacturers.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. Unless otherwise specified, it should work in most POSIX-compliant environments.

2. Intel and AMD Microcode

Microcode lives and executes inside the processor. Before the P6 microarchitecture available from the end of 1995, all microcode was on a ROM. However, since the inception of P6, all Intel and AMD architectures support ways to modify the microcode without special hardware tools or a total product recall.

For example, such an operation might be useful when correcting issues, patching bugs, or even when troubleshooting and debugging. For instance, special microcode is available for debug modes and internal tests.

Microcode distributions are small (around 2kB) binary blobs. Separate blocks within the blob mostly use different encodings. In addition, the information includes data about compatible processors to avoid faults. Critically, microcode blobs are usually encrypted.

Importantly, while Intel provides microcode for Linux along with a tool to apply and update it, AMD mostly relies on the OEM (Original Equipment Manufacturer) and UEFI or BIOS updates to apply a more recent version.

3. Check Current Microcode

The current processor model and microcode version information is available in the output of dmesg and the contents of /proc/cpuinfo:

$ dmesg | grep microcode
[...]
[    6.660010] microcode: microcode updated early to new patch_level=0x66601000
[    6.660100] microcode: CPU1: patch_level=0x66601000
[    6.660101] microcode: CPU0: patch_level=0x66601000
[...]
$ cat /proc/cpuinfo
[...]
vendor_id       : [...]
cpu family      : 21
model           : 66
model name      : [...]
stepping        : 1
microcode       : 0x66601000
[...]

Here, we can see the cpu family and model data, which relates to the information within the binary blob for the processor. Further, the microcode hexadecimal value confirms the current version. Usually, newer versions have higher numbers.

This information can also verify any updates.

4. Microcode Packages

As with most system functionality, packages are mostly available to handle microcode updates fairly automatically. In fact, this is one of the two recommended ways of updating microcode, the other being BIOS and UEFI updates. Yet, even the latter is often also provided as separate native packages within most major Linux distributions.

Still, in Debian and Debian-based systems like Ubuntu, two main packages provide the necessary code and data for available microcode upgrades with a dummy package handling the transition from an older toolset:

• microcode.ctl: transitional dummy package for compatibility
• intel-microcode: Intel processor microcode and tool (iucode-tool)
• amd64-microcode: AMD processor microcode

Thus, the update process is fairly simple for Intel processors in recent Debian-based Linux distributions:

$ apt update && apt install intel-microcode

The same should hold true for AMD, but might not do the trick, depending on the exact processor:

$ apt update && apt install amd64-microcode

Notably, a reboot is required after microcode updates:

$ reboot

Naturally, the backports repository can get a more recent microcode version earlier than the stable repository. However, critically, because of the tiny blob size per processor, microcode for all processors is within the same package. This means that the availability of a more recent package doesn’t necessarily mean a microcode update is available for a specific processor.

Similar packages are available for other Linux distributions as well. However, while they are the recommended approach along with BIOS and UEFI updates, we might want to apply a patch that isn’t already in the official distribution repository package.

5. Manual Microcode Handling

As already mentioned, the microcode itself is distributed as binary blobs.

This means that, in theory, we should be able to download the microcode and install it via a tool and process that work for the manufacturer.

5.1. Download Microcode Package

For Intel, all available microcode exists within a single file available in an official Intel GitHub repository. On the other hand, AMD doesn’t readily provide a convenient consolidated source for its microcode.

Because of this, several projects have created such consolidated sources of most available microcode packages such as https://github.com/platomav/CPUMicrocodes.

After locating and downloading the appropriate package, we can check whether it contains more recent microcode for the system processor family and model.

5.2. Check Available Microcode

Intel separately provides the iucode_tool tool for unpacking, checking, and installing microcode packages:

$ apt update && apt install iucode-tool
[...]
$ mkdir /tmp/ucode
$ iucode_tool -K/tmp/ucode <microcode_package_file>
[...]
$ modprobe cpuid && iucode_tool -tb -lS /tmp/ucode
[...]

Here, we should be able to see the latest microcode that iucode_tool selects for the current system. This way, we can compare it with the current microcode and see whether we need an update.

When it comes to AMD, we often rely on the fairly old amd-ucodegen tool that reads raw AMD microcode files as provided by the platomav repository, which follows a specific naming convention.

Again, the reason behind this is that AMD microcode packages are often distributed by OEM or BIOS and UEFI updates, so separate binary blobs are rarely available. Instead, various unofficial tools and projects handle the extraction and distribution process.

5.3. Manually Install Intel Microcode

To begin with, we must always match the binary microcode file data with the current processor and microcode information. This is a critical step.

The purely manual way of installing Intel microcode is officially deemed unsafe by the manufacturer, which suggests that native Linux packages or BIOS and UEFI updates should be used instead. Yet, the iucode_tool is able to handle installations and updates.

Effectively, we can attempt to manually mimic what a native Linux package would do. Because of this, the process is relatively complex and distribution-specific.

It’s usually best to install microcode updates as early as possible during the boot cycle. This is to avoid any problematic processor behavior from triggering beforehand.

If the Linux kernel version is at least 3.9, we can use the so-called early microcode update method:

1. use iucode_tool –write-earlyfw to generate an earlyfw image (usually under /boot/) from the microcode files (usually under /lib/firmware/intel*)
2. prepend the earlyfw image to initramfs [OR] load earlyfw before the standard initramfs
3. boot with a compatible (CONFIG_MICROCODE_EARLY=y, CONFIG_MICROCODE_INTEL_EARLY=y) Linux kernel >= v3.9

Let’s see an example of how this process looks in practice for Debian:

$ iucode_tool -S --write-earlyfw=/boot/iucode.img /lib/firmware/intel-ucode/*
$ update-initramfs -k all -u

However, we might also need the so-called late microcode update driver: the microcode kernel module. It should either be loaded via modprobe or compiled in (CONFIG_MICROCODE=y). In essence, the method boils down to copying the correct binary file with the correct name (as provided by iucode_tool -K) in the distribution firmware directory (often /lib/firmware/intel-ucode/) and loading or reloading the microcode module:

$ modprobe microcode
$ echo 1 > /sys/devices/system/cpu/microcode/reload # Linux version >= 3.6
$ for i in /sys/devices/system/cpu/cpu[0-9]*/microcode/reload ; do # Linux version <= 3.5
    echo 1 2>/dev/null > "$i" || true
  done

In case of issues, the iucode_tool manual and the iucode-tool repository documentation can provide aid.

5.4. Manually Install AMD Microcode

Of course, the process starts by matching the binary file data with the processor and microcode information on the current system. For AMD microcode packages, the matching is mostly by filename. Still, getting this wrong can result in a non-bootable system.

However, these files might require further processing by the amd-ucodegen utility, so they can become usable by the microcode loader. Usually, the processed packages need to go under a specific distribution-dependent path (often /lib/firmware/amd-ucode/).

So, the process is more straightforward once we select the correct binary file:

1. clone https://github.com/AndyLavr/amd-ucodegen
2. use make to build the amd-ucodegen tool
3. use amd-ucodegen with the binary file as an argument to generate a microcode_amd*.bin file
4. preserve the original file from the firmware path (usually /lib/firmware/amd-ucode/)
5. update the initramfs to load the binary file at boot

For example, let’s see how the last three steps might look in Debian:

$ ./amd-ucodegen cpu66601000_ver66601100_2025-03-03_DABEEF610.bin # generates a file like microcode_amd_fam17h.bin under /lib/firmware/amd-ucode/
$ mv /lib/firmware/amd-ucode/microcode_amd_fam17h.bin /backup/microcode_amd_fam17h.bin.org
$ mv microcode_amd_fam17h.bin /lib/firmware/amd-ucode/
$ update-initramfs -k all -u

In practice, the filename and exact subdirectory location of the AMD microcode blob within the firmware directory is dictated by the cpu family:

• amd-ucode/microcode_amd.bin: 16 (10h), 17 (0x11), 18 (0x12), 20 (0x14)
• amd-ucode/microcode_amd_fam15h.bin: 21 (0x15)
• amd-ucode/microcode_amd_fam16h.bin: 22 (0x16)
• amd-ucode/microcode_amd_fam17h.bin: 23 (0x17)
• amd/amd_sev_fam17h_model0xh.sbin: 23 (0x17)
• amd/amd_sev_fam17h_model3xh.sbin: 23 (0x17)
• amd-ucode/microcode_amd_fam19h.bin: 25 (0x19)
• amd/amd_sev_fam19h_model0xh.sbin: 25 (0x19)

This should be handled by the amd-ucodegen tool.

For both the Intel and AMD microcode, a reboot finalizes the process. To verify the update, we again check the current system processor microcode version as we did before.

6. Summary

In this article, we dived into processor microcode and saw how to check and update it in Linux for two major processor manufacturers.

In conclusion, microcode is rarely crucial and updates often ship with machine firmware, but understanding how to control it from Linux provides administrators with the flexibility and tools to work on and diagnose problems on a lower level.