Updating Intel CPU microcode from Gentoo Linux

Updates to CPU microcode have to be re-applied each time the computer is booted, because the memory updated is volatile (despite the term ‘firmware’ also being used for microcode). Below I describe two methods (there are others) of applying CPU microcode updates in Gentoo Linux. My main laptop has an Intel CPU so I focus here on Intel microcode updates. The procedure is almost the same for AMD CPUs, but the AMD CPU binary update file (‘binary blob’) is installed by the sys-kernel/linux-firmware package.

METHOD 1: Use an initscript in the boot runlevel with a kernel module

Until recently I was using an initscript named microcode_ctl, which uses a program (also named microcode_ctl) and a kernel module (microcode.ko) to update the Intel CPU microcode during boot. This was straightforward to set up in Gentoo Linux:

1. Build the kernel with CONFIG_MICROCODE=m and CONFIG_MICROCODE_INTEL=y.

This is what I configured in the kernel:

# grep -i microcode /usr/src/linux/.config
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_MICROCODE_INTEL_EARLY is not set
# CONFIG_MICROCODE_AMD_EARLY is not set

2. Install two packages and add an OpenRC initscript to the boot runlevel:

# emerge microcode-data microcode-ctl
# rc-update add microcode_ctl boot

The initscript will re-update the CPU microcode every time the computer is rebooted.

Installing the package microcode-data downloads a compressed file (microcode-yyyymmdd.tgz) from the Intel Download Centre, extracts a text file named microcode.dat and parses the text in it to create a set of binary ‘blobs’ in the directory /lib/firmware/intel-ucode/ (one blob for each model of Intel CPU).

Before rebooting, check the revision of microcode in the CPU (the microcode revision is shown for each logical core):

# This is for the Core i7-720QM CPU in my Compal NBLB2 laptop.
# grep microcode /proc/cpuinfo
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3
microcode : 0x3

If I use this method of updating the microcode, the initscript runs after the message ‘Waiting for uevents to be processed ...‘ is displayed on VT1 while booting. After the module has performed the update, the microcode revision in the CPU’s logical cores has changed:

# grep microcode /proc/cpuinfo
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
# dmesg | grep microcode
[ 15.749533] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x3
[ 15.834790] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x3
[ 15.835530] microcode: CPU0 updated to revision 0x7, date = 2013-08-20
[ 15.835544] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x3
[ 15.835587] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x3
[ 15.836241] microcode: CPU1 updated to revision 0x7, date = 2013-08-20
[ 15.836257] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x3
[ 15.836299] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x3
[ 15.836953] microcode: CPU2 updated to revision 0x7, date = 2013-08-20
[ 15.837063] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x3
[ 15.837128] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x3
[ 15.837767] microcode: CPU3 updated to revision 0x7, date = 2013-08-20
[ 15.837857] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
[ 15.837968] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x3
[ 15.838605] microcode: CPU4 updated to revision 0x7, date = 2013-08-20
[ 15.838634] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
[ 15.838681] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x3
[ 15.839357] microcode: CPU5 updated to revision 0x7, date = 2013-08-20
[ 15.839390] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
[ 15.839453] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x3
[ 15.840121] microcode: CPU6 updated to revision 0x7, date = 2013-08-20
[ 15.840180] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
[ 15.840274] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x3
[ 15.840911] microcode: CPU7 updated to revision 0x7, date = 2013-08-20
[ 15.840997] microcode: Microcode Update Driver: v2.00 , Peter Oruba
[ 26.940662] microcode: Microcode Update Driver: v2.00 removed.

Notice that the microcode update occurred in the period from 15.749533 to 15.840997 seconds after the kernel started running, and the microcode was updated from revision 0x3 to 0x7.

METHOD 2: Use the kernel’s built-in Early Update driver

Although the initscript method works perfectly in my case and the update is complete by the time the laptop has finished booting, I wanted to update the CPU microcode earlier. Updating microcode early can fix CPU issues before they occur during kernel boot time. It is possible to configure the kernel to update microcode early by setting CONFIG_MICROCODE_EARLY and CONFIG_MICROCODE_INTEL_EARLY in the kernel. See /usr/src/linux/Documentation/x86/early-microcode.txt for details. That document only refers to initrd files, but, in fact, it also applies to initramfs files.

The Early Update kernel driver will align misaligned microcode data (see Notes on Intel Microcode Updates and [PATCH 7/8] x86, microcode, intel: guard against misaligned microcode data), but you can pre-align the data yourself if you wish by using a .padding file as explained on the latter page. However I did not bother doing that; I leave the Early Update kernel driver to take care of aligning the microcode, as the time penalty to align it is small compared to the overall update time.

It is possible to download the latest compressed Intel microcode data file yourself from the Intel Download Centre. The latest file released is microcode-20140913.tgz at the time of writing. It contains only a text file named microcode.dat, not the required binary blob. Actually, microcode.dat contains data in text format for several Intel CPU models. The microcode.dat file should reside in the directory /lib/firmware/. In the case of Gentoo it is a waste of time manually obtaining the microcode.dat file this way, as there is no tool in Gentoo specifically for creating a binary blob from the microcode.dat file. Therefore just install the Gentoo package sys-apps/microcode-data (which you would have done in any case if you were using the microcode_ctl initscript to load the microcode update to the CPU) and it will automatically download the compressed file from the Intel Web site, unpack it, copy the file microcode.dat to /lib/firmware/ and create the binary blobs in the directory /lib/firmware/intel-ucode/.

You may have read of a tool named intel-microcode2ucode used in other Linux distributions. Gentoo does not build intel-microcode2ucode (the source code of which is included in the Gentoo package sys-apps/microcode-data) as a stand-alone tool, but the act of installing microcode-data creates the required binary files in /lib/firmware/intel-ucode/. i.e. the following command does the complete job:

# emerge microcode-data

Check that the microcode files for the various CPU models were created when microcode-data was installed:

# ls /lib/firmware/intel-ucode/
06-03-02 06-05-03 06-06-0d 06-08-01 06-09-05 06-0b-04 06-0f-02 06-0f-0b 06-17-07 06-1c-02 06-1e-05 06-2a-07 06-3a-09 06-3e-07 0f-00-07 0f-02-05 0f-03-02 0f-04-03 0f-04-09 0f-06-05
06-05-00 06-06-00 06-07-01 06-08-03 06-0a-00 06-0d-06 06-0f-06 06-0f-0d 06-17-0a 06-1c-0a 06-25-02 06-2d-06 06-3c-03 06-3f-02 0f-00-0a 0f-02-06 0f-03-03 0f-04-04 0f-04-0a 0f-06-08
06-05-01 06-06-05 06-07-02 06-08-06 06-0a-01 06-0e-08 06-0f-07 06-16-01 06-1a-04 06-1d-01 06-25-05 06-2d-07 06-3e-04 06-45-01 0f-01-02 0f-02-07 0f-03-04 0f-04-07 0f-06-02
06-05-02 06-06-0a 06-07-03 06-08-0a 06-0b-01 06-0e-0c 06-0f-0a 06-17-06 06-1a-05 06-1e-04 06-26-01 06-2f-02 06-3e-06 06-46-01 0f-02-04 0f-02-09 0f-04-01 0f-04-08 0f-06-04

I looked in /proc/cpuinfo to confirm the model of CPU in my laptop:

$ grep model /proc/cpuinfo
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz

I was able to find the CPUID and other data for that model from the Web site CPU World:

CPUID	106E5
Family	6 (06 hex)
Model	30 (1E hex)
Stepping	5 (05 hex)

Therefore the file /lib/firmware/intel-ucode/06-1e-05 (Family–Model–Stepping in hexadecimal) is the binary blob for my specific CPU model.

First I used genkernel to rebuild the current kernel with CONFIG_MICROCODE_EARLY=y and CONFIG_MICROCODE_INTEL_EARLY=y.

# mount /dev/sda3 /boot # /boot is on a separate partition in my installation.

# Backup the files of the existing kernel image and initramfs:
# cp /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1 /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak
# cp /boot/kernel-genkernel-x86_64-3.17.1-gentoo-r1 /home/fitzcarraldo/kernel-genkernel-x86_64-3.17.1-gentoo-r1.bak
# cp /boot/System.map-genkernel-x86_64-3.17.1-gentoo-r1 /home/fitzcarraldo/System.map-genkernel-x86_64-3.17.1-gentoo-r1.bak

# Now rebuild the kernel:
# zcat /proc/config.gz > /usr/src/config
# genkernel --kernel-config=/usr/src/config --menuconfig --splash=Emergance --disklabel all # Set CONFIG_MICROCODE_EARLY and CONFIG_MICROCODE_INTEL_EARLY.
# emerge @module-rebuild
# grub2-mkconfig -o /boot/grub/grub.cfg

This is what I have after rebuilding the kernel:

# grep -i microcode /usr/src/linux/.config
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_EARLY=y
# CONFIG_MICROCODE_AMD_EARLY is not set
CONFIG_MICROCODE_EARLY=y

Then I prepended the cpio file containing the binary blob to the initramfs file (see the instructions in /usr/src/linux/Documentation/x86/early-microcode.txt):

# mkdir -p /boot/initrd/kernel/x86/microcode
# cd /boot/initrd
# cp /lib/firmware/intel-ucode/06-1e-05 kernel/x86/microcode/GenuineIntel.bin
# find . | cpio -o -H newc >../ucode.cpio
# cd ..
# cp /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1 /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak.early # Backup the recently-built initramfs first.
# cat ucode.cpio /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1 >/boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.ucode
# cp /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.ucode /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1
# rm /boot/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.ucode
# umount /boot
# rc-update del microcode_ctl boot # Disable the initscript so that microcode.ko will no longer be used when I reboot.

Reboot.

Use the following commands to check if the CPU microcode has been updated:

# grep microcode /proc/cpuinfo
# dmesg | grep microcode

There is no point looking in /var/log/messages, because syslog-ng has not started running when the early microcode update occurs.

# grep microcode /proc/cpuinfo
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
microcode : 0x7
# dmesg | grep microcode
[ 0.252234] CPU1 microcode updated early to revision 0x7, date = 2013-08-20
[ 0.265389] CPU2 microcode updated early to revision 0x7, date = 2013-08-20
[ 0.278696] CPU3 microcode updated early to revision 0x7, date = 2013-08-20
[ 1.888471] microcode: CPU0 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888481] microcode: CPU1 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888491] microcode: CPU2 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888498] microcode: CPU3 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888506] microcode: CPU4 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888515] microcode: CPU5 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888523] microcode: CPU6 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888534] microcode: CPU7 sig=0x106e5, pf=0x10, revision=0x7
[ 1.888597] microcode: Microcode Update Driver: v2.00 , Peter Oruba

Compare the update time in the dmesg output above with the update time in the dmesg output for an update done using the initscript (Method 1, further up). With the Early Update driver, the update was complete in 0.278696 seconds. With the initscript and kernel module, the update was complete in 15.840911 seconds. Quite a difference.

I do not know why the dmesg output does not have a message for Core 0 in the group of messages before 1.000000 second elapsed. The message at 1.888471 shows it was updated, so I assume the kernel ring buffer was not large enough and the message was overwritten. Cores 1, 2 and 3 were updated in the period between 0.252234 and 0.278696 seconds, and then all eight logical cores are listed in the period between 1.888471 and 1.888597 seconds. I’m not sure of the precise messages expected, but they look similar to the results obtained by users in other distributions, such as the following CrunchBang Linux output:

$ uname -a
Linux crunchbang 3.10-12.dmz.1-liquorix-amd64 #1 ZEN SMP PREEMPT Sun Sep 15 17:29:51 UTC 2013 x86_64 GNU/Linux
$ dmesg | grep microcode
CPU0 microcode updated early to revision 0x19, date = 2013-06-13
CPU1 microcode updated early to revision 0x19, date = 2013-06-13
CPU2 microcode updated early to revision 0x19, date = 2013-06-13
CPU3 microcode updated early to revision 0x19, date = 2013-06-13
microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU4 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU5 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU6 sig=0x306a9, pf=0x10, revision=0x19
microcode: CPU7 sig=0x306a9, pf=0x10, revision=0x19
microcode: Microcode Update Driver: v2.00 , Peter Oruba
$ cat /proc/cpuinfo | grep microcode | uniq
microcode : 0x19

Finally, I deleted the temporary work directory and files:

# mount /dev/sda3 /boot
# rm -rf /boot/initrd/
# rm /boot/ucode.cpio
# rm /home/fitzcarraldo/kernel-genkernel-x86_64-3.17.1-gentoo-r1.bak
# rm /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak
# rm /home/fitzcarraldo/System.map-genkernel-x86_64-3.17.1-gentoo-r1.bak

# Optional. Could keep the following file in case Intel issues a new microcode.dat file and I want to create a new concatenated initramfs file:
# rm /home/fitzcarraldo/initramfs-genkernel-x86_64-3.17.1-gentoo-r1.bak.early

Of course, you will need to repeat the whole process and create a new concatenated initramfs file in any of the following cases:

a) you build a new version of the kernel;

b) you rebuild the current version of the kernel with different configuration settings;

c) Intel releases a new version of the microcode (which does not happen often).

It seems the Early Update driver still has some bugs, so I expect the message output to change in future kernel releases. See e.g. [PATCH 0/8] x86, microcode, intel: fixes and enhancements, [PATCH 3/8] x86, microcode, intel: clarify log messages, Re: [PATCH 3/8] x86, microcode, intel: clarify log messages and a bunch of other very recent posts in the kernel mailing list regarding the Early Update driver and CPU microcode updates.

UPDATE (September 1, 2015): Since I wrote the above post, the use of a kernel module and initscript to update CPU microcode has been dropped (in Gentoo Linux, at least). This is because updating CPU microcode relatively late in the boot process may cause problems if some processes have started before the update has taken place. The only safe way to update CPU microcode is to use the kernel’s built-in Microcode Early Update driver (METHOD 2 above). New versions of the relevant Gentoo Linux ebuilds (microcode-ctl-1.28-r1, microcode-data-20150121-r1 and iucode_tool-1.3) have recently been released (see Gentoo Bug Report No. 528712). If a Gentoo Linux installation does not use an initramfs, the microcode-data ebuild now includes an ‘initramfs‘ USE flag which you can set in order to create a minimal initramfs to load the CPU microcode at boot (see my latest post for details).