Updating CPU Microcode in LFS

stoat · 10-23-2012, 11:38 PM

Introduction

Intel and AMD both provide for updating processor microcode during booting. Updating the CPU microcode is a volatile update, so it needs to be performed during each system boot. It does not permanently "reflash" the CPU. If the CPU microcode update is not repeated at every system boot, the CPU reverts back to the original microcode. Intel periodically releases a file named microcode.dat that contains the data to update the CPU microcode. AMD releases its update data as a tarball containing various .bin files. I mostly am going to address updating the microcode for Intel processors since I don't own any AMD processors, but the steps described later include updating AMD processors.

In the past, the Intel CPU microcode was updated by an executable named microcode_ctl which would read microcode.dat and update the CPU microcode during booting. That executable was launched by an init script also named microcode_ctl. More recently, a driver included with the Linux kernel has been used to update the CPU microcode. The driver module is named microcode and is part of the kernel’s configuration established when the kernel is built. An important difference nowadays when using the kernel driver to update the CPU microcode is that the microcode.dat file released by Intel has to be converted to the so-called ucode format using an executable named intel-microcode2ucode. The resulting ucode files are read by the kernel microcode driver during booting and used to update the CPU microcode.

Regardless of the method of updating the microcode, past or present, a software package was, and still is, installed to provide the executables and do the tasks mentioned above. That software package has generally been, and still is, known as microcode_ctl in distro binaries and as source code.

Installing the microcode_ctl Package

Most distros now use the kernel microcode update driver described next. Not only that, but the current versions of the microcode_ctl source package no longer install an init script. The last source version of microcode_ctl that I know of that installed an init script was microcode_ctl-1.17 from 2007. The current versions of the microcode_ctl package now contain source code for building and installing the executable intel-microcode2ucode which converts the Intel microcode.dat file to the ucode format, tarballs containing the current CPU microcode update data for Intel and AMD processors, and document files. Installing the current version of microcode_ctl accomplishes the following tasks...

Build the executable intel-microcode2ucode
Untar the included tarball with the Intel microcode.dat file
Run the intel-microcode2ucode executable which converts microcode.dat into individual ucode files
Untar the included tarball with the AMD .bin files and docs
Create the destination directories
Install the intel-microcode2ucode executable in /usr/local/sbin
Install the Intel README docs in /usr/local/share/doc/microcode_ctl
Install the Intel ucode files in /lib/firmware/intel-ucode
Install the AMD .bin files in /lib/firmware/amd-ucode
Install the AMD docs in /usr/local/share/doc/microcode_ctl

The microcode_ctl source package is installed as shown next after extracting the source tarball and changing directories to the build directory. I use the sed to install intel-microcode2ucode and the docs in /usr instead of /usr/local since there is no --prefix option to do that. Omit the sed to install the files in /usr/local.

Code:

sed -i 's@/usr/local@/usr@' Makefile
make all

As root...

Code:

make install

The current source tarball for microcode_ctl is microcode_ctl-2.0-2.tar.xz and can be downloaded from fedoraproject.org...

http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl

This is an example of the Intel ucode data files you should see in /lib/firmware/intel-ucode. The names of the files are in the format of $family-$model-$stepping. Not all Intel processors will have an update...

Code:

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

This is an example of the AMD .bin data files you should see in /lib/firmware/amd-ucode...

Code:

$ ls /lib/firmware/amd-ucode/
microcode_amd.bin  microcode_amd_fam15h.bin  microcode_amd_solaris.bin

Configuring the Kernel

The kernel configuration should have the following to build the microcode update driver as a module (see them in "Processor type and features"). Recompile the kernel if it is not configured to do the microcode update. Also, I recommend not setting CONFIG_MICROCODE to built-in (=y). I feel it should be a module since the data the driver needs will be in the filesystem. The kernel will automatically load the module during booting and perform the microcode update.

CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y

When the microcode is updated, the dmesg messages will have the relevant information about the update. Example...

Code:

$ dmesg | grep microcode
microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa07
microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa07
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
microcode: CPU0 updated to revision 0xa0b, date = 2010-09-28
microcode: CPU1 updated to revision 0xa0b, date = 2010-09-28

Updating the Data Files

AMD and Intel periodically release new microcode data files. For AMD, one would need only to download the latest tarball from AMD, untar it, and copy the new .bin files to /lib/firmware/amd-ucode. But Intel still releases its microcode data as that microcode.dat file which is not compatible with the kernel update driver. Use /usr/sbin/intel-microcode2ucode to convert microcode.dat to the ucode files for the kernel driver to use. Another strategy to update the data files would be to re-install a new version of the whole microcode_ctl source package again. It would contain the new data. A purist might uninstall the old package first, or at least delete the old intel-ucode and amd-ucode folders in /lib/firmware.

References

http://downloadcenter.intel.com/Deta...inux+microcode
http://www.amd64.org/support/microcode.html
http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl/
http://linux.die.net/man/8/microcode_ctl
https://wiki.archlinux.org/index.php/Microcode
https://www.archlinux.org/packages/?name=intel-ucode
https://www.archlinux.org/packages/?name=amd-ucode

Keith Hedger · 10-24-2012, 05:18 AM

How safe is this? Can I brick my CPU?

stoat · 10-24-2012, 08:45 AM

Quote:

Originally Posted by Keith Hedger

How safe is this? Can I brick my CPU?

I don't think I'm in a position to directly answer those questions. I will defer that task to Intel, AMD, and the developers of the kernel and the related software. But I can sort of indirectly answer them with some comments and anecdotes.

Firstly, I can report that I have been using microcode_ctl in Fedora for as long as I can remember using Fedora (a long time). I remember installing the microcode_ctl rpm package and then periodically downloading microcode.dat from Intel. When I installed Fedora 17 recently, the default installation included microcode_ctl. And when I boot that Fedora 17 system, the microcode module is loaded and dmesg reports the update driver ran. I didn't do anything to make any of that happen in Fedora 17.

I also used Arch Linux for a couple of years. I always installed the package for the microcode update. I was using Arch when it switched from the init method of doing the update to the kernel driver method. The package changed from microcode_ctl to ucode-intel and ucode-amd. And "microcode" was moved from the DAEMONS array to the MODULES array. It's still that way today at ArchWiki.

I came to BLFS from Arch. Again, I have always installed microcode_ctl in my BLFS systems. But until recently, I had been installing the older version that installed an init script (microcode_ctl-1.7). It did not deal with AMD which was okay since I don't use AMD. It installed microcode.dat in /etc which also was okay because, unlike the newer kernel update driver, the microcode_ctl executable uses microcode.dat for the update data. The init script was a problem because it was designed for Linux distros and would attempt the guess the distro and enable the init script. But that always failed because it didn't expect LFS. I rewrote my own simplified init script for LFS. It worked fine. Now I have discovered the kernel update driver and how to use it in LFS instead of the init script.

When I did the research for this thread, I remember seeing one or two forum posts in which people asked your questions. But I never saw one in which someone reported any hardware damage. That doesn't really mean much, but it's at least something worth reporting. I will leave it at that and charge you with the responsibility of assessing whether or not you should update your CPU microcode (if it even has an update). After all, people can break their systems after being told to re-install GRUB in a forum post.

But I do thank you for asking those questions. They prompted me to add some text to the Introduction section and some more references.

druuna · 10-24-2012, 08:53 AM

Quote:

Can I brick my CPU?

Like stoat I cannot answer the question directly, but I've been using microcode_ctl in Debian Squeeze and never had a problem (intel i7 cpu).

Just thought I'd let you know

EDIT:

stoat: Nice article!

Keith Hedger · 10-24-2012, 09:34 AM

Thanks for the replys I've got an AMD and can't seem to find a definitive answer anyone else use a AMD athlon duel core that has done this?

re_nelson · 03-30-2013, 02:19 PM

Quote:

Originally Posted by stoat

Intel and AMD both provide for updating processor microcode during booting. Updating the CPU microcode is a volatile update, so it needs to be performed during each system boot. It does not permanently "reflash" the CPU. If the CPU microcode update is not repeated at every system boot, the CPU reverts back to the original microcode. Intel periodically releases a file named microcode.dat that contains the data to update the CPU microcode. AMD releases its update data as a tarball containing various .bin files. I mostly am going to address updating the microcode for Intel processors since I don't own any AMD processors, but the steps described later include updating AMD processors.

I'm bringing this past thread back to life to express my appreciation to stoat for the well-written instructions. I followed it almost to the letter and not only did it not turn my i7-3770K processor into a doorstop but the end result was that a clean, error-free upgrade occurred:

Code:

microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU0 updated to revision 0x17, date = 2013-01-09
microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU1 updated to revision 0x17, date = 2013-01-09
microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU2 updated to revision 0x17, date = 2013-01-09
microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU3 updated to revision 0x17, date = 2013-01-09
microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU4 updated to revision 0x17, date = 2013-01-09
microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU5 updated to revision 0x17, date = 2013-01-09
microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU6 updated to revision 0x17, date = 2013-01-09
microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x16
microcode: CPU7 updated to revision 0x17, date = 2013-01-09
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

The only deviation from the steps outlined is that rather than deal with the full microcode_ctl package, I obtained just the necessary
intel-microcode2ucode.c source from this URL:

https://github.com/pld-linux/microcode-data-intel

273 · 04-01-2013, 09:22 AM

It looks like amd64.org no longer exists? This seems like an appropriate place to ask whether anyone knows about the availability of microcode for AMD Bulldozer processors?
Debian does have a package but I can't find anywhere to check whether I have "the most up to date" microcode.

stoat · 04-01-2013, 08:57 PM

I have no way to know really, but I suspect that the firmware in the Debian package or the latest source tarball at the fedoraproject.org link in post #1 will be the latest version. The fedoraproject source tarball is dated late last year. The microcode.dat version currently available at downloadcenter.intel.com still is 20120606-v2. Looking around, I never saw any dates much after those dates for this microcode stuff (but that doesn't really mean much). Judging by the old version release dates at fedoraproject.org and the Debian package's changelog, I don't think this microcode stuff gets updated very often anyway.

About the amd64.org thing, there is this (FWIW)...

https://lkml.org/lkml/2012/12/20/2

273 · 04-02-2013, 04:48 AM

Thanks. It was mainly out of curiosity and also in case of any bug fixes being released.