[SOLVED] How to load new Intel microcode

Petri Kaukasoina · 05-15-2019, 01:47 PM

Quote:

Originally Posted by abga

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.

deNiro · 05-15-2019, 03:01 PM

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

Skaendo · 05-15-2019, 03:29 PM

Quote:

Originally Posted by deNiro

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.

abga · 05-15-2019, 06:38 PM

Quote:

Originally Posted by Petri Kaukasoina

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

Skaendo · 05-16-2019, 08:36 PM

Apparently another GitHub tag released:

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

abga · 05-17-2019, 02:27 PM

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

teoberi · 05-17-2019, 03:09 PM

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!

abga · 05-17-2019, 05:46 PM

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.

Skaendo · 05-17-2019, 05:49 PM

Quote:

Originally Posted by abga

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/

abga · 05-17-2019, 06:10 PM

Quote:

Originally Posted by Skaendo

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.

deNiro · 05-18-2019, 02:20 AM

Quote:

Originally Posted by abga

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.

abga · 05-18-2019, 10:23 AM

@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.

teoberi · 05-20-2019, 12:45 PM

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 ...

deNiro · 06-03-2019, 03:28 AM

Quote:

Originally Posted by Skaendo

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.

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