Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load Intel microcode using pre-compiled EFI stub #175

Closed
whiskerz007 opened this issue May 7, 2021 · 4 comments
Closed

Load Intel microcode using pre-compiled EFI stub #175

whiskerz007 opened this issue May 7, 2021 · 4 comments

Comments

@whiskerz007
Copy link

Adding initrd= to the commandline does not seem to load the Intel microcode in Arch Linux (other operating systems have not been tested). The following is the results from booting with or without initrd=.

[root@arch ~]# dmesg | grep microcode
[    0.131880] SRBDS: Vulnerable: No microcode
[    0.589734] microcode: sig=0x906ea, pf=0x20, revision=0xb4
[    0.590258] microcode: Microcode Update Driver: v2.2.
[root@msi-arch impish]#  bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -
iucode_tool: system has processor(s) with signature 0x000906ea
microcode bundle 1: (stdin)
selected microcodes:
  001/185: sig 0x000906e9, pf_mask 0x2a, 2020-05-26, rev 0x00de, size 104448
  001/186: sig 0x000906ea, pf_mask 0x22, 2020-05-25, rev 0x00de, size 103424
  001/187: sig 0x000906eb, pf_mask 0x02, 2020-05-25, rev 0x00de, size 104448
  001/188: sig 0x000906ec, pf_mask 0x22, 2020-06-03, rev 0x00de, size 103424
  001/189: sig 0x000906ed, pf_mask 0x22, 2020-05-24, rev 0x00de, size 103424
[root@arch ~]# grep microcode /proc/cpuinfo 
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
microcode       : 0xb4
[root@arch ~]# 

The following is an example of the working environment.

[root@arch ~]# cat /proc/cmdline 
zfs=zroot/ROOT/archlinux zfs_import_dir=/dev/disk/by-id rw loglevel=3 acpi_osi=! acpi_osi="Windows 2009" nouveau.modeset=0 spl_hostid=00000000 initrd=./intel-ucode.img
root@arch ~]# zfs list
NAME                   USED  AVAIL     REFER  MOUNTPOINT
zroot                 13.0G   102G       98K  none
zroot/ROOT            11.9G   102G       98K  none
zroot/ROOT/archlinux  11.9G   102G     11.3G  /
zroot/data            1.00G   102G       98K  none
zroot/data/home       1.00G   102G     1.00G  /home
zroot/data/home/root  1.76M   102G     1.76M  /root
[root@arch ~]# 

The following parameters have been attempted without success.

initrd=intel-ucode.img
initrd=/intel-ucode.img
initrd=/boot/intel-ucode.img
initrd=/@/boot/intel-ucode.img
initrd=/ROOT/archlinux/@/boot/intel-ucode.img
initrd=zroot/ROOT/archlinux/@/boot/intel-ucode.img

Please advise.

@ahesford
Copy link
Member

ahesford commented May 7, 2021

ZFSBootMenu has no way to load an early microcode image because it relies on kexec and that is only capable of loading a single image. Dracut can prepend the early microcode image to your regular initramfs.

You have three options:

  1. Switch to dracut on Arch. I don't know how painful this will be.
  2. Use late loading or build in the microcode.
  3. Try to use the dracut method on your ZFSBootMenu image, and see if the microcode patches persist after the kexec into your BE.

Of all these options, I think you should just use late loading to force your Arch kernel to reload microcode after boot.

@ahesford
Copy link
Member

ahesford commented Jun 1, 2021

Closing because there is nothing ZFSBootMenu can do to address early microcode loading.

@ahesford ahesford closed this as completed Jun 1, 2021
@digitalsignalperson
Copy link

Adding my notes here for anyone else who might try this:

Tried this

cd /boot
mv initramfs-linux.img initramfs-linux.img.orig
cat intel-ucode.img initramfs-linux.img.orig > initramfs-linux.img

If I boot with grub using this concatenated image (ensuring removing the original microcode img from the grub.cfg initrd command), I boot and I see the microcode loaded (dmesg | grep microcode).

If I try zbm, while it does boot with the concatenated image, I don't see microcode loaded in dmesg. I'm not sure if this is something I'm doing wrong, or some reason this fundamentally can't work.

Discussion in mkinitcpio repo about including microcode in image, and how it's just cat'ing them together (which worked for me with grub at least) https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/191

As far as late loading, I don't know what to make of the warning around late loading = dangerous

Late loading (dangerous) updates the microcode after booting which could be too late since the CPU might have already tried to use a faulty instruction. Even if already using early loading, late loading can still be used to apply a newer microcode update without needing to reboot.

@jasonthagerty
Copy link

I know that this is a little out of date...
I solved for this by adding an install hook in my mkinitcpio that extracts the microcode binary from the provided cpio image file and includes it in my initramfs image under /kernel/x86/microde/GenuineIntel.bin. It looks like the loader dosen't support compression so I'm using cat for the compression value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants