Not 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
Related Posts:
I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.
I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308
- One Week From Tomorrow…THE WORLD WILL LOSE THEIR MINDS!Lines Are Already Forming! - November 21, 2024
- Crunchbits Discontinuing Popular Annual Plans – The Community Mourns! - November 20, 2024
- RackNerd’s Black Friday 2024: Bigger, Better, and Now in Dublin! - November 19, 2024
Leave a Reply