LinuxQuestions.org - [SOLVED] How to load new Intel microcode

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - How to load new Intel microcode (https://www.linuxquestions.org/questions/slackware-14/how-to-load-new-intel-microcode-4175621053/)

Quote:

Originally Posted by kjhambrick (Post 5851373)

I was not exactly sure what to do about the new intel-ucode-with-caveats/ directory but it is in the Package as /lib/firmware/intel-ucode-with-caveats/ if you want to use it.

In addition, the new Kernel Patches Directory is stored as /usr/doc/intel-microcode-20180425/linux-kernel-patches/

The firmware in intel-ucode-with-caveats/ is for a tiny number of Broadwell CPUs (certain Xeon E5 v4s are affected, AFAIK). The patches in linux-kernel-patches/ need to be applied to 4.4.x and 4.9.x kernel source trees (although apparently Intel is working on getting them backported) to prevent those CPUs from hanging when the firmware is uploaded. The kernel patches are otherwise unnecessary.

Quote:

Originally Posted by CTM (Post 5853877)

Thanks for the info CTM.

After building and installing intel-microcode.SlackBuild attached in the post above, you'll find two README files:

Code:

/usr/share/doc/intel-microcode-20180425/RELEASE_NOTE:

/usr/share/doc/intel-microcode-20180425/linux-kernel-patches/patch-readme

Reading these two files, the firmware for S-M-F == '06-4f-01' ( aka Xeon E5/E7 v4 and Core i7-69xx/68xx ) was moved from /lib/firmware/intel-ucode/ to /lib/firmware/intel-ucode-with-caveats/ with the 20180425 ucode update.

If you run one of these Skylake CPUs and you need to 'live load' the microcode for the processors and you're running a 4.4.y or 4.9.y Kernel, you'll need the kernel patches.

And as you said, these patches are being back-ported so the patches should be OBE at that point.

Or something like that ... :)

-- kjh

Intel Page for Linux * Processor Microcode:
https://downloadcenter.intel.com/dow...le?product=873

Quote:

Version: Latest (Latest) Date: 8/7/2018

Quote:

Other Versions microcode-20190312

https://downloadmirror.intel.com/287...ode_readme.txt
What is this? Does anyone have more information?

seems to be landed on debian but not adopted widely

https://repology.org/project/intel-microcode/packages

https://metadata.ftp-master.debian.o...o9+1_changelog

the fact that intel points for the latest version at 20180807 could mean that something might be wrong with the newer version but I hasn't been able to find no reports of this.
it might also mean that the new version hasn't been throughly tested but I haven't been able to find any information also in this sense...

Why is it not downloading from Intel servers but from GitHub?
It may be related to kernel 4.19.29 where a microcode update is announced.
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.19.29

The new Intel microcode-20190312 works well for a few days, even though I do not know exactly the answer to the previous questions.

I think to recompile kernel for stable is ok - but what about -current? And please would someone be so kind to made some short summary of this thread - seems here are so many solutions of the problem stated I am completely lost - most promising for me looks what (resurrected) dark side of force proposed - I mean to concatenate initrd.gz - seems nice trick and sppose works in other situations - mhm I would really be interested to hear for what other purposes this trick can be used.

A different approach

Not the Slackware way, but seems easier to me.

http://linuxfromscratch.org/blfs/vie.../firmware.html

HTH
John

Actually its not the SBo way I guess

Thanks for this thread, i used this method describe by BradPitt
https://www.linuxquestions.org/quest...ml#post5803641

I think worked, here my load using spectro script
According to the script i am not vulnerable at all

Code:

Spectre and Meltdown mitigation detection tool v0.40



Checking for vulnerabilities on current system

Kernel is Linux 5.0.10 #1 SMP Tue Apr 30 10:39:48 -03 2019 x86_64

CPU is Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz



Hardware check

* Hardware support (CPU microcode) for mitigation techniques

  * Indirect Branch Restricted Speculation (IBRS)

    * SPEC_CTRL MSR is available:  YES 

    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)

  * Indirect Branch Prediction Barrier (IBPB)

    * PRED_CMD MSR is available:  YES 

    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)

  * Single Thread Indirect Branch Predictors (STIBP)

    * SPEC_CTRL MSR is available:  YES 

    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)

  * Speculative Store Bypass Disable (SSBD)

    * CPU indicates SSBD capability:  YES  (Intel SSBD)

  * L1 data cache invalidation

    * FLUSH_CMD MSR is available:  YES 

    * CPU indicates L1D flush capability:  YES  (L1D flush feature bit)

  * Enhanced IBRS (IBRS_ALL)

    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO 

    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO 

  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 

  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO 

  * CPU/Hypervisor indicates L1D flushing is not necessary on this system:  NO 

  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO 

  * CPU supports Software Guard Extensions (SGX):  NO 

  * CPU microcode is known to cause stability problems:  NO  (model 0x3a family 0x6 stepping 0x9 ucode 0x20 cpuid 0x306a9)

  * CPU microcode is the latest known available version:  YES  (latest version is 0x20 dated 2018/04/10 according to builtin MCExtractor DB v96 - 2019/01/15)

* CPU vulnerability to the speculative execution attack variants

  * Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass):  YES 

  * Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection):  YES 

  * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load):  YES 

  * Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read):  YES 

  * Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass):  YES 

  * Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault):  NO 

  * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault):  YES 

  * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault):  YES 



CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'

* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)

* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())

* Kernel has the Red Hat/Ubuntu patch:  NO 

* Kernel has mask_nospec64 (arm64):  NO 

> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)



CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'

* Mitigated according to the /sys interface:  YES  (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling)

* Mitigation 1

  * Kernel is compiled with IBRS support:  YES 

    * IBRS enabled and active:  YES  (for firmware code only)

  * Kernel is compiled with IBPB support:  YES 

    * IBPB enabled and active:  YES 

* Mitigation 2

  * Kernel has branch predictor hardening (arm):  NO 

  * Kernel compiled with retpoline option:  YES 

    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)

> STATUS:  NOT VULNERABLE  (Full retpoline + IBPB are mitigating the vulnerability)



CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'

* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)

* Kernel supports Page Table Isolation (PTI):  YES 

  * PTI enabled and active:  YES 

  * Reduced performance impact of PTI:  YES  (CPU supports PCID, performance impact of PTI will be reduced)

* Running as a Xen PV DomU:  NO 

> STATUS:  NOT VULNERABLE  (Mitigation: PTI)



CVE-2018-3640 aka 'Variant 3a, rogue system register read'

* CPU microcode mitigates the vulnerability:  YES 

> STATUS:  NOT VULNERABLE  (your CPU microcode mitigates the vulnerability)



CVE-2018-3639 aka 'Variant 4, speculative store bypass'

* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

* Kernel supports disabling speculative store bypass (SSB):  YES  (found in /proc/self/status)

* SSB mitigation is enabled and active:  YES  (per-thread through prctl)

* SSB mitigation currently active for selected processes: readlink: falta operando

Tente "readlink --help" para mais informações.

basename: falta operando

Tente "basename --help" para mais informações.

 NO  (no process found using SSB mitigation through prctl)

> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)



CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'

* CPU microcode mitigates the vulnerability:  N/A 

> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)



CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'

* Mitigated according to the /sys interface:  YES  (Mitigation: PTE Inversion)

* Kernel supports PTE inversion:  YES  (found in kernel image)

* PTE inversion enabled and active:  YES 

> STATUS:  NOT VULNERABLE  (Mitigation: PTE Inversion)



CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'

* Information from the /sys interface: VMX: conditional cache flushes, SMT vulnerable

* This system is a host running a hypervisor:  NO 

* Mitigation 1 (KVM)

  * EPT is disabled:  NO 

* Mitigation 2

  * L1D flush is supported by kernel:  YES  (found flush_l1d in /proc/cpuinfo)

  * L1D flush enabled:  YES  (conditional flushes)

  * Hardware-backed L1D flush supported:  YES  (performance impact of the mitigation will be greatly reduced)

  * Hyper-Threading (SMT) is enabled:  YES 

> STATUS:  NOT VULNERABLE  (this system is not running a hypervisor)



> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK

On a Haswell U laptop (i3 - DELL) I tried the following:
- downloaded the latest Intel microcode pack:
https://github.com/intel/Intel-Linux...0190514.tar.gz
- unpacked the archive, got rid of the top level folder and repacked it into:
microcode-20190514.tgz
- used the Slackbuild form here:
http://www.slackbuilds.org/repositor...tel-microcode/
- changed in intel-microcode.SlackBuild

Code:

#from

VERSION=${VERSION:-20180807}

#to

VERSION=${VERSION:-20190514}

- build it & installed it & rebooted, only to find out that my CPU microcode wasn't updated, remained at its original revision=0x24 instead of updating to revision=0x25
- the release note form:
https://github.com/intel/Intel-Linux...0190514.tar.gz
contains:

Code:

HSW-U C0/D0 6-45-1/72 00000024->00000025 Core Gen4

- and the guide, on page 9 - bottom, has my CPU listed with the new revision=0x25
https://www.intel.com/content/dam/ww...e_05132019.pdf

Code:

Haswell U

4th Generation Intel® Core™ 

Processor Family

Intel® Pentium® Processor Family

- well, either my CPU isn't yet supported/updated, this Intel microcode pack is still "beta" or ... I might have messed up something with the intel-microcode pack/SlackBuild. I double checked the last point and everything looks OK.

There's also a positive side to this, the latest spectre-meltdown-checker was happy to report that I'm "doomed" (never mind CVE-2018-3646)
https://github.com/speed47/spectre-meltdown-checker

Code:

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'

* CPU supports the MD_CLEAR functionality:  NO

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Neither your kernel or your microcode support mitigation, upgrade both to mitigate the vulnerability)



CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'

* CPU supports the MD_CLEAR functionality:  NO

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Neither your kernel or your microcode support mitigation, upgrade both to mitigate the vulnerability)



CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'

* CPU supports the MD_CLEAR functionality:  NO

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Neither your kernel or your microcode support mitigation, upgrade both to mitigate the vulnerability)



CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'

* CPU supports the MD_CLEAR functionality:  NO

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Neither your kernel or your microcode support mitigation, upgrade both to mitigate the vulnerability)



> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:KO CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO

..................................

@AlleyTrotter
Thanks, that's the one I used. You actually quoted my link pointing to the same release ;)

Quote:

Originally Posted by abga (Post 5995115)

- build it & installed it & rebooted, only to find out that my CPU microcode wasn't updated, remained at its original revision=0x24 instead of updating to revision=0x25

If you use lilo and load the microcode via its initrd= keyword, did you remember to run (mkinitrd and) lilo?

Quote:

Originally Posted by Petri Kaukasoina (Post 5995161)

If you use lilo and load the microcode via its initrd= keyword, did you remember to run (mkinitrd and) lilo?

Thanks for the tip. I'm not using initrd and I checked if the microcode update driver was loaded on boot:

Code:

# dmesg | grep micro

[    3.680854] microcode: CPU0 sig=0x40651, pf=0x40, revision=0x24

[    3.681004] microcode: CPU1 sig=0x40651, pf=0x40, revision=0x24

[    3.681188] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

It's a Haswell i3-4005U DELL Laptop, kind of a test system / road warrior. Until now, DELL has always (promptly) published a BIOS update once Intel released their microcode. I still believe that there's actually no update for this CPU in Intel's latest microcode release ... will wait for DELL to confirm/infirm (BIOS update).

Quote:

Originally Posted by abga (Post 5995350)

Thanks for the tip. I'm not using initrd and I checked if the microcode update driver was loaded on boot:

Code:

# dmesg | grep micro

[    3.680854] microcode: CPU0 sig=0x40651, pf=0x40, revision=0x24

[    3.681004] microcode: CPU1 sig=0x40651, pf=0x40, revision=0x24

[    3.681188] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

I still believe that there's actually no update for this CPU in Intel's latest microcode release

Yes, there is:

Code:

$ iucode_tool -L /lib/firmware/intel-ucode/06-45-01

microcode bundle 1: /lib/firmware/intel-ucode/06-45-01

  001/001: sig 0x00040651, pf_mask 0x72, 2019-02-26, rev 0x0025, size 21504

I don't use initrd either, but I have initrd=/boot/intel-ucode.cpio in /etc/lilo.conf to "update microcode early":

Code:

[    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17

[    4.302678] microcode: sig=0x206a7, pf=0x2, revision=0x2f

[    4.302900] microcode: Microcode Update Driver: v2.2.

Justr a question: instead of using these patches, could one also just disable hyperthreading? Since most of the meltdown spectre stuff is releated to that

Quote:

Originally Posted by deNiro (Post 5995396)

Justr a question: instead of using these patches, could one also just disable hyperthreading? Since most of the meltdown spectre stuff is releated to that

That wont work for everyone. I for one depend on HT for compile jobs. I compile things like qt5 where hyperthreading GREATLY reduces build times. As it is, it takes me about 6 hours to compile qt5 (2 core w/HT @ 3.4GHz running jobs at -j8) and if I didn't use HT, it would take ~20 hours.

I suppose that if you are disabling it for general purpose (browsing the web etc) on a personal level you might not notice the performance difference, BUT I don't think that it would be beneficial to devs and (large?) package maintainers.

Then there are programs like Waterfox that use multiple cores/threads and that makes a big difference in performance of that particular program as well.

Quote:

Originally Posted by Petri Kaukasoina (Post 5995376)

Yes, there is:

Code:

$ iucode_tool -L /lib/firmware/intel-ucode/06-45-01

microcode bundle 1: /lib/firmware/intel-ucode/06-45-01

  001/001: sig 0x00040651, pf_mask 0x72, 2019-02-26, rev 0x0025, size 21504

I don't use initrd either, but I have initrd=/boot/intel-ucode.cpio in /etc/lilo.conf to "update microcode early":

Code:

[    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17

[    4.302678] microcode: sig=0x206a7, pf=0x2, revision=0x2f

[    4.302900] microcode: Microcode Update Driver: v2.2.

Thanks again for your help & clarifications. Meanwhile I was looking for docs to learn more about the microcode update process, stumbled upon:
Gentoo:
https://wiki.gentoo.org/wiki/Intel_microcode

Quote:

Important
The microcode-ctl utility has been deprecated as of version 1.28-r1(Gentoo unstable)[1] and no longer contains the init script. It also does not work on certain CPUs such as Intel Haswells...

Arch:
https://wiki.archlinux.org/index.php/Microcode#LILO

Quote:

LILO and potentially other old bootloaders do not support multiple initrd images. In that case, cpu_manufacturer-ucode.img and initramfs-linux.img will have to be merged into one image.

This is what I knew and wasn't aware that I could only add initrd=/boot/intel-ucode.cpio on its own in /etc/lilo.conf, without merging it with an actual initrd image. Will try it

Apparently another GitHub tag released:

https://github.com/intel/Intel-Linux...code-20190514a

Cool, "continuous delivery" over github...

Hope they'll also start to provide a way to enable the update of the Intel AMT firmware under Linux.
https://www.intel.com/content/www/us...-sa-00213.html

The same problem for Intel ME.
For a fairly good ASUS motherboard I had to mount another HDD, install Windows 10 and run "ME update tool". Of course, Windows 10 has deleted the Slackware option from the UEFI menu. Good luck with rEFInd that immediately booted my Slackware.
Will I have to take it over again!

With initrd=/boot/intel-ucode.cpio in /etc/lilo.conf I get now the microcode update:

Code:

dmesg | grep micro

[    0.000000] microcode: CPU0 microcode updated early to revision 0x25, date = 2019-02-26

[    0.094863] microcode: CPU1 microcode updated early to revision 0x25, date = 2019-02-26

[    3.681301] microcode: CPU0 sig=0x40651, pf=0x40, revision=0x25

[    3.681451] microcode: CPU1 sig=0x40651, pf=0x40, revision=0x25

[    3.681669] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

And the spectre-meltdown-checker script is happy with the CPU but not with the kernel:

Code:

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'

* CPU supports the MD_CLEAR functionality:  YES

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)



CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'

* CPU supports the MD_CLEAR functionality:  YES

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)



CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'

* CPU supports the MD_CLEAR functionality:  YES

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)



CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'

* CPU supports the MD_CLEAR functionality:  YES

* Kernel supports using MD_CLEAR mitigation:  NO

> STATUS:  VULNERABLE  (Your microcode supports mitigation, but your kernel doesn't, upgrade it to mitigate the vulnerability)

Hope Patrick will find some time to compile & distribute the new 4.4.180 kernel.

Quote:

Originally Posted by abga (Post 5996246)

Hope Patrick will find some time to compile & distribute the new 4.4.180 kernel.

Until then, you can get Idlemoor's "DUSK" (Dave's Unofficial Slackbuilt Kernels) 4.4.180 kernels from here: https://dusk.idlemoor.tk/linux-4.4/

Quote:

Originally Posted by Skaendo (Post 5996247)

Until then, you can get Idlemoor's "DUSK" (Dave's Unofficial Slackbuilt Kernels) 4.4.180 kernels from here: https://dusk.idlemoor.tk/linux-4.4/

Thanks! Not that much in rush, better have it tested - ready before deployment, I'm patient, trusting Patrick.

Quote:

Originally Posted by abga (Post 5996246)

With initrd=/boot/intel-ucode.cpio in /etc/lilo.conf I get now the microcode update:

Hope Patrick will find some time to compile & distribute the new 4.4.180 kernel.

Compiling that kernel on your own is not so hard. It involves only a few commands, and when using the ".config" from the kernel you're currently running, it requires hardly any thinking. You can even first test it out as a secondary option in your lilo bootloader, or keep your current kernel as backup.

@deNiro
Thanks for the hint, I'm familiar with compiling kernels, don't worry, I just don't see the point in doing it. I (re)build & maintain enough apps on my own, don't need to worry about the kernel too. As said above, I'm not in a hurry and I trust Patrick with the kernel, in fact I never had any issues with his kernel compilation in the last period (over 5 years). Up until the 2.4-2.6 era I did compile my own kernels.

The link to the microcode posted on GitHub disappeared from Intel's web page for Linux* Processor Microcode Data File.
The latest version is: 20180807!
Strange or maybe not ...

Quote:

Originally Posted by Skaendo (Post 5995405)

I understand. I also do compile stuff now and then, like a new kernel, or packages from slackbuilds, and some small stuff of my own.

And although I am no expert on the matter, I assume these patches are not really sufficient, and I follow the openBSD route of disabling hyperthreading/smt altogether, by booting the kernel with the "nosmt" kernel parameter. And I don't suffer much from that.

For practical reasons, i.o.w. when I have to compile large programs, I enable hyperthreading temporarily, since newer kernels have SMT control on the live system ( works on the kernel that ships with slackware-current)

to temporarily enable hyperthreading:
echo on > /sys/devices/system/cpu/smt/control

and to disable it again:
echo off > /sys/devices/system/cpu/smt/control

You can see the effects of this settings immediately with for example htop