LowEndBox - Cheap VPS, Hosting and Dedicated Server Deals

How to Update Intel Microcode on Debian 11 Bullseye

Intel InsideNot long ago I noticed this message when booting one of my home systems:

“TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)”

I wasn’t having any issues with the system, but this sounded like something I should correct.  But doing a microcode upgrade sounded risky – couldn’t brick my CPU?  And while an apt-cache search quickly found a package called intel-microcode, it was listed as not available.  Time to investigate.

The system in question has an Intel i5-4690 from circa 2014 and I’m running Debian Bullseye 11.1.

After doing a little more research, I noticed that doing a “dmesg | grep -i microcode” produced a number of messages related to CPU microcode:

[ 0.015642] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
[ 0.067475] TAA: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.067475] SRBDS: Vulnerable: No microcode
[ 0.067476] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.869517] microcode: sig=0x306c3, pf=0x2, revision=0x19
[ 0.869548] microcode: Microcode Update Driver: v2.2.

By microcode, Debian is referring to the software that sits on the Intel microprocessor (CPU) itself.  Many people think of CPUs as pure silicon but in fact an x86 processor (and many other microprocessors) contains onboard software that is executed.  For example, the old 80486 had approximately 250 lines of microcode, totally 12,032 bits stored in its ROM (read only memory) (Wikipedia).  This is very common in many types of processors besides CPUs.

Starting with the P6 series (mid 1990s), Intel CPUs contain not only manufacturer-loaded ROM but also field-loaded volatile memory which can be updated by users.  This facility exists so you fixes can be distributed to end users for loading.

You can’t write your own microprocessor microcode because the CPU will only accept signed blobs.  Also, you can’t brick your CPU (render it useless) because any microcode is loaded into volatile memory.  Once you turn your computer off, all volatile memory is lost and the CPU reverts back to its factory condition.  So if you obtain and load a microcode fix, you need to have a mechanism to load this microcode every time you start your computer.  In Linux, this is done by loading it at boot-time (as part of initrd typically).  Other Unix-like OSes have similar facilities.

Back to my home computer.  Looking at /proc/cpuinfo, I can see the microcode version:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz
stepping : 3
microcode : 0x19

I can also see the bugs detected by the Linux kernel.  Debian Bullseye 11.1 uses Linux kernel 5.10 and reports:

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds

Some of those probably look familiar from news reports: Meltdown, Spectre, etc.

So how can I update my microcode?

On Debian, there is a package called intel-microcode.  There is also amd-microcode, so adjust as needed for your platform.

You have to enable the non-free software components because, as a signed blob loaded into the CPU, it’s not free software in the licensing sense.  So first, make sure your /etc/apt/sources list looks something like this:

deb http://ftp.us.debian.org/debian/ bullseye main contrib non-free
deb-src http://ftp.us.debian.org/debian/ bullseye main contrib non-free

deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free

Next, install the intel-microcode package:

# apt-get install intel-microcode
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
iucode-tool
The following NEW packages will be installed:
intel-microcode iucode-tool
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 3,897 kB of archives.
After this operation, 4,932 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.us.debian.org/debian bullseye/contrib amd64 iucode-tool amd64 2.3.1-1 [62.4 kB]
Get:2 http://ftp.us.debian.org/debian bullseye/non-free amd64 intel-microcode amd64 3.20210608.2 [3,834 kB]
Fetched 3,897 kB in 2s (2,361 kB/s) 
Selecting previously unselected package iucode-tool.
(Reading database ... 335743 files and directories currently installed.)
Preparing to unpack .../iucode-tool_2.3.1-1_amd64.deb ...
Unpacking iucode-tool (2.3.1-1) ...
Selecting previously unselected package intel-microcode.
Preparing to unpack .../intel-microcode_3.20210608.2_amd64.deb ...
Unpacking intel-microcode (3.20210608.2) ...
Setting up iucode-tool (2.3.1-1) ...
Setting up intel-microcode (3.20210608.2) ...
update-initramfs: deferring update (trigger activated)
intel-microcode: microcode will be updated at next boot

And now reboot.  At boot-time, the Intel microcode load will be triggered and you’ll see a message like this (or issue a dmesg | grep -i microcode to see it later):

[ 0.000000] microcode: microcode updated early to revision 0x28, date = 2019-11-12
[ 0.067434] SRBDS: Mitigation: Microcode
[ 0.807409] microcode: sig=0x306c3, pf=0x2, revision=0x28
[ 0.807429] microcode: Microcode Update Driver: v2.2.

Sure enough, when I look in /proc/cpuinfo I see my microcode has been updated:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz
stepping : 3
microcode : 0x28

And while not all bugs are gone – this is a pretty old CPU and Intel is not releasing fixes for every one – we got rid of the one the kernel was complaining about:

Before:

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds

After:

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds

 

 

raindog308

No Comments

    Leave a Reply

    Some notes on commenting on LowEndBox:

    • Do not use LowEndBox for support issues. Go to your hosting provider and issue a ticket there. Coming here saying "my VPS is down, what do I do?!" will only have your comments removed.
    • Akismet is used for spam detection. Some comments may be held temporarily for manual approval.
    • Use <pre>...</pre> to quote the output from your terminal/console, or consider using a pastebin service.

    Your email address will not be published. Required fields are marked *