Advice: Where to capture custom Microcode system requirements/setup?

eduncan911 · 2018-10-30 15:29:00

Intel (and perhaps AMD, can't test that yet) microcode patching. I am wondering where the best place is to capture this fix/resolution. Wiki for Xen->UEFI microcode? Perhaps patching the `Intel-ucode` package? maybe edit the Xen->Microcode wiki page?

Problem:

`xen.cfg` cannot use the `intel-ucode.img` microcode binary produced by the `intel-ucode` system package. Typical resolutions to this for other bootloaders is to specify multiple ramdisk lines - but tat panics the kernel (only reads 1). Another is specifying multiple imgs on the single ramdisk line, however the Xen EFI bootloader considers that configuration invalid and quickly exits.

Resolution:

Create a "patched" initramfs-linux.img file:

# cat /boot/intel-ucode.img /boot/initramfs-linux.img > /boot/intel-ucode_initramfs-linux.img

And then change `/boot/xen.cfg` to use this new patched ramdisk.

[global]
default=xen

[xen]
options=console=vga conswitch=a hardware_dom=0 core_parking=power dom0_mem=1024M,max:1024M dom0_max_vcpus=4 iommu=force:true,qinval:true,debug:true loglvl=all noreboot=true reboot=no sched=credit2 sched_credit_tslice_ms=30 sched_ratelimit_us=1000 sched_smt_power_savings=false vga=ask ucode=scan
kernel=vmlinuz-linux root=/dev/mmcblk0p2 rootfstype=ext4 rw add_efi_memmap earlyprintk=xen
ramdisk=intel-ucode_initramfs-linux.img

You can verify the fix with:

$ sudo xl dmesg | grep microcode
(XEN) microcode: CPU0 updated from revision 0x28 to 0x32, date = 2018-05-11
(XEN) microcode: CPU2 updated from revision 0x28 to 0x32, date = 2018-05-11

And...

$ sudo xl dmesg | grep Speculative -A5
(XEN) Speculative mitigation facilities:
(XEN)   Hardware features: IBRS/IBPB STIBP RDCL_NO SSB_NO
(XEN)   Compiled-in support: INDIRECT_THUNK
(XEN)   Xen settings: BTI-Thunk JMP, SPEC_CTRL: IBRS+, Other: IBPB
(XEN)   Support for VMs: PV: MSR_SPEC_CTRL RSB, HVM: MSR_SPEC_CTRL RSB
(XEN)   XPTI (64-bit PV only): Dom0 disabled, DomU disabled

I believe the "hardware features" line would be empty if the BIOS or Microcode does not have any patches.

But where to capture this fix?

If everyone thinks this goes into the Xen wiki, then i'll need to write a systemd-monitor script to monitor for updates to intel-ucode to rebuild/repatch this same file with the latest. It kind of makes sense for Xen AUR Wiki.

But again, it's kind of knowledge that should be shared by other bootloaders that cannot boot multiple initramfs - which means the Microcode Wiki.

To fix it at the package level, I could contact the author of the `intel-ucode` package (and possibly the AMD package once I get my new AMD desktop) to possibly generate this kind of file for bootloaders that can only use a single initramfs (e.g. xen hypervisor). Maybe something like intel-ucode-initramfs-linux.img - but even that means it only uses one, and not a fallback version (meaning multiples to create). So that is more system specific that may not be ideal.

So.. Where do you recommend we capture this info (besides buried down in the forums, of course)?

Last edited by eduncan911 (2018-10-30 16:13:26)

sheep_42 · 2018-10-30 15:48:27

There seems to be a ucode=<filename> in xen.cfg (https://xenbits.xen.org/docs/unstable/misc/efi.html), that's maybe what you are looking for.

eduncan911 · 2018-10-30 16:00:47

sheep_42 wrote:

There seems to be a ucode=<filename> in xen.cfg (https://xenbits.xen.org/docs/unstable/misc/efi.html), that's maybe what you are looking for.

Ah, sorry I forgot to report those errors. I did that early on; however, it does not accept initrd `intel-ucode.img` binary from the intel-ucode package.

Instead it wants the raw "GenuineIntel.bin" that you download from the Intel site - which the Intel-ucode package does, extracts, modifies with a tool and packages up into the intel-ucode.img.

Thanks for reminding me (forgot during this ordeal). This was another thought I had in contacting the author, to keep the GenuineIntel.bin file around placed in a common directory to allow for custom setups like this. Currently, the intel-ucode package simply supplies the intel-ucode.img and a license file - that's it. The PKGBUILD extracts it to the temp srcdir - where it gets ignored and not installed.

Other linux distros keep the file around in a common /lib/firmware/intel-ucode/ kind of location, for use with other tools. Perhaps that what we should do with the intel-ucode package?

For completion sake, I scrolled back and found the errors produced when using that `ucode=intel-ucode.img` line:

# in xen.cfg, we have "ucode=intel-ucode.img"

$ sudo xl dmesg | grep microcode
(XEN) microcode: error! Bad data in microcode data file
(XEN) microcode: error! Bad data in microcode data file
(XEN) microcode: error! Bad data in microcode data file
(XEN) microcode: error! Bad data in microcode data file

And the meltdown/spectra tests confirms no microcode patch was applied.

Also, when trying to specify it as the options= line, using ucode=<filename>, that generated a Xen EFI configuration error message in dmesg as well:

$ sudo xl dmesg | grep intel
(XEN) parameter "ucode" has invalid value "intel-ucode.img", rc=-22!

However... Do note that you need to enable "options= ... ucode=scan" for the above concatenation resolution to work with the single image file.

This does work however:

[global]
default=xen

[xen]
options=console=vga conswitch=a hardware_dom=0 core_parking=power dom0_mem=1024M,max:1024M iommu=force:true,qinval:true,debug:true loglvl=all noreboot=true reboot=no sched=credit2 sched_credit_tslice_ms=30 sched_ratelimit_us=1000 sched_smt_power_savings=false vga=ask ucode=scan
kernel=vmlinuz-linux root=/dev/mmcblk0p2 rootfstype=ext4 rw add_efi_memmap earlyprintk=xen
ramdisk=initramfs-linux.img
ucode=GenuineIntel.bin

Notice the last line.

Now, if the package author of `intel-ucode` could just install the `GenuineIntel.bin` to the same location they are installing the `intel-ucode.img`, we'd be in business with no more mods to the system. And... it will remain updated! However, even if the package author installs it to `/lib/firmware/intel-ucode/`, that's still a good place to reference to tell users to setup a monitor to copy the latest to /boot/.

All while leaving all of their custom initramfs files alone!

Last edited by eduncan911 (2018-10-30 18:38:53)

Lone_Wolf · 2018-11-01 09:44:00

This will affect both intel-ucode and amd-ucode packages and there's an underlying question that hasn't been mentioned yet.

https://www.kernel.org/doc/Documentatio … rocode.txt states :

The microcode is stored in an initrd file. During boot, it is read from
it and loaded into the CPU cores.
The format of the combined initrd image is microcode in (uncompressed)
cpio format followed by the (possibly compressed) initrd image. The
loader parses the combined initrd image during boot.

That suggests to me Xen should support the current method, not ask distros to change how they deal with microcode early loading.

I'm just one archlinux user though , issues like this should be discussed by archlinux developers.

The arch-general mailing list seems the best option to get in touch with them.

eduncan911 · 2018-11-01 10:26:19

Lone_Wolf wrote:

This will affect both intel-ucode and amd-ucode packages and there's an underlying question that hasn't been mentioned yet.
https://www.kernel.org/doc/Documentatio … rocode.txt states :
The microcode is stored in an initrd file. During boot, it is read from
it and loaded into the CPU cores.
The format of the combined initrd image is microcode in (uncompressed)
cpio format followed by the (possibly compressed) initrd image. The
loader parses the combined initrd image during boot.

I read that quote (good find!) as saying there should only be 1 file - a combined microcode+initfrd file.

That is in fact what I had to do to get it to work - combine the microcode cpio initrd image with the system's initrd into a single file. (the cat command in the OP).

...and, that is what the intel-ucode package does not do today! If that is in fact what Kernel.org is saying to do, then it's the intel-ucode/amd-ucode packages that aren't following the directions and combining them as they should. Instead, the packages just dumps a separate intel-ucode.img and amd-ucode.img out - to let the bootloaders (and people) figure out how to load them.

That suggests to me Xen should support the current method, not ask distros to change how they deal with microcode early loading.

Xen does support this "combined" initrd image stated from that kernel.org quote, and it's what i am using currently. I originally posted that as the solution in the first post. There is a "ucode=scan" command line option that can be passed in, and it works.

However, like I said above, it only works from the "combined" version of the initrd file, not two separate files as the microcode packages produce.

I'm just one archlinux user though , issues like this should be discussed by archlinux developers.
The arch-general mailing list seems the best option to get in touch with them.

Thanks! Will do.

Arch Linux

#1 2018-10-30 15:29:00

Advice: Where to capture custom Microcode system requirements/setup?

#2 2018-10-30 15:48:27

Re: Advice: Where to capture custom Microcode system requirements/setup?

#3 2018-10-30 16:00:47

Re: Advice: Where to capture custom Microcode system requirements/setup?

#4 2018-11-01 09:44:00

Re: Advice: Where to capture custom Microcode system requirements/setup?

#5 2018-11-01 10:26:19

Re: Advice: Where to capture custom Microcode system requirements/setup?

Board footer