[SOLVED] How to set up early load of Intel firmware

hazel · 05-18-2019, 11:28 AM

I've just downloaded an updated version of my cpu firmware that is supposed to deal with the Zombiload exploit. I've installed it in LFS using the instructions given in BLFS. Basically you put it in a cpio archive and set this to be your initrd.

I now want to do the same in Slackware. But my Slackware installation already has an initrd that I made to go with the generic kernel. The BLFS book says you can specify two initrds if you put the uncompressed one with the kernel firmware first, but they are talking about GRUB and I don't know if the same applies in lilo/elilo. Can I do this in elilo.conf? Or should I put the kernel/x86/microcode tree which contains the firmware into the initrd tree and remake initrd.gz?

Petri Kaukasoina · 05-18-2019, 11:56 AM

man mkinitrd...

Code:

       -P microcode_archive
              This  option  specifies  a  cpio  archive   containing   updated
              microcode  for your CPU.  CPU manufacturers occasionally release
              such updates to fix bugs in the microcode currently embedded  in
              the  CPU.  The microcode archive will be prepended to the output
              initrd, where the kernel will find it for early patching:

                -P /boot/intel-ucode.cpio

hazel · 05-18-2019, 12:14 PM

Perfect! Thanks a lot.

Lysander666 · 05-18-2019, 01:13 PM

I found a Slackbuild for this here:

https://slackbuilds.org/repository/1...tel-microcode/

For my own reference, would installing this be sufficient [and its depend?]

hazel · 05-18-2019, 02:18 PM

Interesting but the build has another dependency (iucode_tool). It's simpler just to copy over and use the cpio file I already have. Especially as the mkinitrd script has a specific option for doing that. Just one of the nice friendly little touches I've noticed in Slackware since I started using it. Everything seems to be crafted to give you smooth working.

Chuck56 · 05-18-2019, 02:20 PM

Quote:

Originally Posted by Lysander666

I found a Slackbuild for this here:

https://slackbuilds.org/repository/1...tel-microcode/

For my own reference, would installing this be sufficient [and its depend?]

It would be a good start but it wouldn't finish the job. Before you make the changes check /var/log/dmesg (1st line best indicator).

BEFORE:

Code:

root@XXXX:/var/log# grep microcode dmesg
[    0.000000] microcode: microcode updated early to revision 0x2b, date = 2018-03-22
[    0.277311] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    3.943957] microcode: sig=0x306d4, pf=0x40, revision=0x2b
[    3.944093] microcode: Microcode Update Driver: v2.2.

If you use an initrd, create a new initrd with the "-P /boot/intel-ucode.cpio" option.

If you use lilo then reboot and check dmesg again.

If you use EFI then copy the new intrd over to the efi partition before reboot and check dmesg again.

If you use grub, oh well, not my jam but you get the idea what needs to be done.

AFTER:

Code:

root@XXXX:/var/log# grep microcode dmesg
[    0.000000] microcode: microcode updated early to revision 0x2d, date = 2019-03-07
[    3.951274] microcode: sig=0x306d4, pf=0x40, revision=0x2d
[    3.951425] microcode: Microcode Update Driver: v2.2.

Enjoy!

abga · 05-18-2019, 03:53 PM

Quote:

Originally Posted by Lysander666

I found a Slackbuild for this here:

https://slackbuilds.org/repository/1...tel-microcode/

For my own reference, would installing this be sufficient [and its depend?]

Just installing it, will create /boot/intel-ucode.cpio and I just reported here that it doesn't always work (depends on CPU):
https://www.linuxquestions.org/quest...ml#post5995482

Even if I don't use initrd (at all) in my lilo configuration, as per Petri Kaukasoina's advice, I had to add initrd=/boot/intel-ucode.cpio on its own in /etc/lilo.conf and update lilo (run lilo).
Reported the success here:
https://www.linuxquestions.org/quest...ml#post5996246

Obviously, if you already use initrd, then you need to merge your initrd image with the intel-ucode.cpio

Lysander666 · 05-19-2019, 11:11 AM

I wish I could add another 'solved' to this but it appears to have worked on my Skylake.

This was the situation before:

Code:

root@lysultra-vi:/var/log# grep microcode dmesg
[    0.040219] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0xb2 (or later)
[    0.258168] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    4.346184] microcode: sig=0x406e3, pf=0x80, revision=0x9e
[    4.346426] microcode: Microcode Update Driver: v2.2.

this is it now:

Code:

root@lysultra-vi:/var/log# grep microcode dmesg
[    0.000000] microcode: microcode updated early to revision 0xcc, date = 2019-04-01
[    4.346985] microcode: sig=0x406e3, pf=0x80, revision=0xcc
[    4.347211] microcode: Microcode Update Driver: v2.2.

and for the first time I have mitigation on spec_store_bypass:

Code:

lysander@lysultra-vi:~$ gawk '{ print FILENAME ":\t" $0 }' /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:	Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/mds:	Mitigation: Clear CPU buffers; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:	Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:	Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:	Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:	Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling

This was using a combination of the microcode Slackbuild and [mostly] Chuck's simple advice.

hazel · 05-20-2019, 05:18 AM

So I decided to update the kernel before I went any further. The one in patches (4.4.172) is an earlier series but LTS, so paradoxically it is more recent. It's the first time I have installed a kernel in Slackware, and I was intrigued to see that the doinst.sh script only made a few useful symbolic links and did not actually change the boot process. I think I can see the philosophical rationale for that: changing the boot is hazardous, so should not be done behind the sysadmin's back.

I made the new initrd and got it right the second time (!). Now, I'm running the new kernel and I piped the intel firmware into /sys/devices to see what would happen. It seems to work OK.

Code:

[ 1728.000678] microcode: CPU0 sig=0x30678, pf=0x4, revision=0x811
[ 1728.003107] microcode: CPU0 updated to revision 0x838, date = 2019-04-22
[ 1728.003370] microcode: CPU1 sig=0x30678, pf=0x4, revision=0x811
[ 1728.005450] microcode: CPU1 updated to revision 0x838, date = 2019-04-22
[ 1728.005661] microcode: CPU2 sig=0x30678, pf=0x4, revision=0x811
[ 1728.008503] microcode: CPU2 updated to revision 0x838, date = 2019-04-22
[ 1728.008993] microcode: CPU3 sig=0x30678, pf=0x4, revision=0x811
[ 1728.011868] microcode: CPU3 updated to revision 0x838, date = 2019-04-22

Code:

 cat /sys/devices/system/cpu/vulnerabilities/*
Not affected
Mitigation: PTI
Not affected
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline

So now I'm going to make yet another initrd image with the -P option to load that stuff at boot.

Lysander666 · 05-20-2019, 05:35 AM

You may not get full mitigation on 14.2 since the last stable, as you know, is 4.4.172 which was released in late Jan. Pat needs to at least release 4.4.180 for stable which has the necessary patches for ZombieLoad.

Mind you, I don't know which CPU you're running. It looks like an older one so maybe you're affected by ZL anyway?

hazel · 05-20-2019, 05:40 AM

Apparently it's a Bay Trail Pentium JS209. But bear in mind that I know damn-all about hardware. The point is that I'm not getting any report of vulnerabilities.

Lysander666 · 05-20-2019, 06:42 AM

You can also run this script, it's a lot more thorough:

https://github.com/speed47/spectre-meltdown-checker

Quote:

Spectre, Meltdown, Foreshadow, Fallout, RIDL, ZombieLoad vulnerability/mitigation checker for Linux & BSD

hazel · 05-20-2019, 07:30 AM

Here's a summary of what I got.

Code:

CVE-2017-5753 Spectre 1: Mitigated, not vulnerable
CVE-2017-7515 Spectre 2: Mitigated, not vulnerable but should enable IBBP
CVE-2017-5754 Meltdown: Mitigated, not vulnerable
CVE-2018-3640 Variant 3A: Vulnerable. More up-to-date firmware required.
CVE-2018-12126 Fallout: Vulnerable. Microcode supports mitigation but kernel does not.
CVE-2018-12130 Zombieload: Vulnerable. Microcode supports mitigation but kernel does not.
CVE-2018-12127 RIDL: Vulnerable. Microcode supports mitigation but kernel does not.
CVE-2019-11091 RIDL: Vulnerable. Microcode supports mitigation but kernel does not.

Looks like that new kernel isn't good enough. Is there a later one in current? I'll go check. Now I've installed one, it should be easy to do another.

Just checked: current has 4.19.44.

btw What is IBBP? I can't find it on duckduckgo.

abga · 05-20-2019, 01:17 PM

Quote:

Originally Posted by hazel

btw What is IBBP? I can't find it on duckduckgo.

Looks like a typo, should be IBPB - Indirect Branch Prediction Barrier
https://access.redhat.com/articles/3...rriers-ibpb-10
https://lwn.net/Articles/764209/

FlinchX · 05-21-2019, 03:06 AM

Quote:

Originally Posted by Chuck56

If you use an initrd, create a new initrd with the "-P /boot/intel-ucode.cpio" option.

The legacy approach works as well:

Code:

cp /boot/initrd.gz /tmp
cat /boot/intel-ucode.cpio /tmp/initrd.gz > /boot/initrd.gz