How to install/update Intel microcode firmware on Linux

Originally published at: https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/

I am a new Linux sysadmin. How do I install or update microcode firmware for Intel/AMD CPUs on Linux using the command line option?

Thats typically a BIOS process. Update the BIOS (if its available) for the motherboard.

Hi, i’m running fedora 27 x64, i’m trying to manually install the download from the intel site.

I tried this command: “sudo update-initramfs -u”

and get the following error:

sudo: update-initramfs: command not found

please update this guide with for fedora users too please.

P.S you should update this guide telling the user to login to terminal as root otherwise this command won’t work:

# echo 1 > /sys/devices/system/cpu/microcode/reload

For Fedora Linux try:

sudo dracut -fv
sudo reboot

Almost all sysadmin command must run as root user. I will update guide later.

In the article provided by you https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/ i don’t see this step on my CentOS 6.5 host. The host is a standalone HP DL Proliant Gen 8

Make sure /sys/devices/system/cpu/microcode/reload exits:
$ ls -l /sys/devices/system/cpu/microcode/reload

PLease advise.

Method 1

CentOS 6.x is older distro with older micocode format for kernel. What you need to do is run the following as root when you use firmware downloaded from Intel site:

yum install microcode_ctl
### extract firmware downladed from the Intel site ###
tar xvf microcode-20180108.tgz
### You will have a file named microcode.dat when extracted copy that one to /lib/firmware/ ###
cp microcode.dat /lib/firmware/microcode.dat
### load firmware #
/sbin/microcode_ctl -u
### Verify it ###  
dmesg | grep microcode

Another option (method 2)

On older kernel such as yours is to to update the microcode.dat to the system, one need:

  1. Ensure the existence of /dev/cpu/microcode
ls -l /dev/cpu/microcode
  1. If exists write microcode.dat to the file, e.g.
 dd if=microcode.dat of=/dev/cpu/microcode bs=1M
  1. Verify it
dmesg | grep microcode

I hope this helps. Let me know. Make sure you reboot the box and verify it with dmesg | grep microcode

Hi I have Arch Linux installed, I have Intel i7 with the cpu incriminate, I looked in:

/lib/firmware/intel-ucode/ and you do not find this directory. I found this directory: /lib/firmware/intel and the microcode is installed by giving:

ls -l /sys/devices/system/cpu/microcode/reload
--w ------- 1 root root 4096 13 Jan 10.08 /sys/devices/system/cpu/microcode/ reload

How should I copy the microcode on an Arch Linux?
Thanks for your help

For Intel processors, install the intel-ucode package. It comes with firmware updated for cpu:

sudo pacman -S intel-ucode
sudo grub-mkconfig -o /boot/grub/grub.cfg
sudo reboot
dmesg | grep microcode

For more info read this page.

Thanks for your help
It is already installed, but it is not the latest patch of intel for spectre and meltdown.

edit
sorry I checked now I have the last patch

Just create that dir and copy it:

sudo mkdir -p  /lib/firmware/intel-ucode/
sudo cp /path/to/your/intel-ucode/*  /lib/firmware/intel-ucode/
sudo sh -c 'echo 1 > /sys/devices/system/cpu/microcode/reload'
sudo sh -c 'dmesg | grep microcode'

If you do not see the following line means Intel did not updated your CPU:

[    0.000000] microcode: microcode updated early to revision 0x17, date = 2017-01-27

Even tho I loaded the latest, it only applied 2017-01-27 release. The reason is simple. Intel only provided update upto 2017-01-27. HTH.

[ettore@yoda-pc firmware]$ sudo sh -c 'dmesg | grep microcode'
[    0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26
[    4.161890] microcode: sig=0x306a9, pf=0x10, revision=0x1c
[    4.162073] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ettore@yoda-pc firmware]$

Edit: I dot not restart,when I restart today I’ll let you know.

Thanks

Hi,

I am very new on Linux. I am having problems to update do the steps that you show here.

The script that you metioned on another post shows that I am not vulerable to Meltdows, but I need to update to fix Spectre vulnerabilities.

I have a Notebook Hp 15-f272wm (Intel Pentium N3540). I am using Lubuntu 17.10.1 release, Artful Aardvark (64-bit version for Intel or AMD computers).

I put:

dmesg | grep microcode

It shows:

[ 5.686805] microcode: sig=0x30678, pf=0x8, revision=0x830
[ 5.687468] microcode: Microcode Update Driver: v2.2.

I check for a microcode update:

sudo apt install intel-microcode

It shows me:

intel-microcode is already in its most recent version (3.20180108.0 ~ ubuntu17.10.1)

I follow the steps to update microcode blob for Linux (20180108 release). When I put:

echo 1 > /sys/devices/system/cpu/microcode/reload

It shows a warning:

cryptsetup: WARNING: target cryptswap1 has a random key, skipped

When I reboot and write on terminal:

dmesg | grep microcode

Keeps showing:

[ 5.686805] microcode: sig=0x30678, pf=0x8, revision=0x830
[ 5.687468] microcode: Microcode Update Driver: v2.2.

¨HP has released a security bulletin for systems with Intel x86 processor¨ here: https://support.hp.com/us-en/document/c05869091

But they have not publish anything related to the HP Notebook PC 15-f2xx

What can I do reggarding to the microcode blob update? It will give me problems with my Notebook?

Just curiosity:

If I format the SO do I have to update again the microcode blob? If i update the microcode and format the SO do I have have to update it again?

Thanks!

Microcode update not released by any distro or Intel yet for normal user. It is only released for big customers like Google Cloud/AWS and so on. At this time only Meltdown patched on all Linux distros. To patch Spectre v1 and v2 you need:

  • Kernel update
  • Microcode blob from Intel

Everyone is waiting for it and there is nothing you can do to fix it. HTH.

1 Like

Really thanks for your answer!.

This is useful. I did installed as you said, and downloaded a diagnosis script from Redhat https://access.redhat.com/security/vulnerabilities/speculativeexecution

But, still, the script says variant 2 aka spectre with CVE-2017-5715 is vulnerable. Any idea? below is my output.

[akandime@hostname~]# ./meltdown_Redhat.sh 

This script is primarily designed to detect Spectre / Meltdown on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

/sys/kernel/debug/x86 is mounted and accessible

The following files are accessible:
/sys/kernel/debug/x86/pti_enabled, /sys/kernel/debug/x86/ibpb_enabled, /sys/kernel/debug/x86/ibrs_enabled
Checking files...

Detected CPU vendor is: Intel

Variant #1 (Spectre): Mitigated
Variant #2 (Spectre): Vulnerable
Variant #3 (Meltdown): Mitigated

For more information see:
https://access.redhat.com/security/vulnerabilities/speculativeexecution

There is another script I download from Github and it also pointed out the same output GitHub - speed47/spectre-meltdown-checker: Reptar, Downfall, Zenbleed, ZombieLoad, RIDL, Fallout, Foreshadow, Spectre, Meltdown vulnerability/mitigation checker for Linux & BSD

[akandime@hostname~]# ./meltdown_spectre_github.sh 
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 17:31:22 UTC 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  YES 
> STATUS:  NOT VULNERABLE  (84 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  YES 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

Does this mean microcode update is not released for any vendor servers like HP, Dell, Supermicro?

That is right. HP, Dell and co including Intel/AMD should release those updates.

But, in below article, you said, to download microcode from Intel site and I did downloaded and applied on my test server.
How to install Intel processor microcode blob for Linux (20180108 release)
Ok, first visit AMD or Intel site to grab the latest microcode firmware. In this example, I have a file named ~/Downloads/microcode-20180108.tgz (don’t forget to check for checksum) that suppose to help with meltdown/Spectre. First extract it using the tar command:
$ mkdir firmware
$ cd firmware
$ tar xvf ~/Downloads/microcode-20180108.tgz
$ ls -l

But, still after applying it is showing as Vulnerable.

Hi Akandina,

I also got same issue with you. Adter patch and reload + reboot Spectre #2 still vulnerable. Its due to the microcde cannot updated. You can verify it with dmesg | grep microcode

Thank you

Bayu Permadi

@Bayu_Permadi/@akandima

Two issues

  • Not all CPUs is going to get microcode updates ASAP. Latest XEON that was purchase in Dec/2017. Got update. But older Intel i7/i5/i3/Pentium/Xeon may or many not see microcode update. That is upto Intel. They will release it slowly. You and I wait.
  • Intel released buggy update. It is so bad all distros and OEM (HP/Dell/Red Hat) are pulling out. microcode-20180108.tgz is no good. We all now waiting for next updated release. Only big vendors and data centre operator like Google/AWS getting correct updates and they had 6 months to fix mess. My advice either wait like everyone else (we don’t have choice here, do we now?) or move to AWS/Google cloud if security is that important.

The warning from RHEL/CentOS for 20180108.tgz is scary too: