X86/64 uses "dangerous" late microcode loading

darksky · February 22, 2025, 1:51pm

I'm wondering if there is a use-case to keep this method of providing microcode updates in play? Upstream deprecated this method years ago.

# dmesg|grep micro
[    1.811137] Register File Data Sampling: Vulnerable: No microcode
[    3.662993] microcode: Microcode Update Driver: v2.2.
[    4.576363] microcode: Attempting late microcode loading - it is dangerous and taints the kernel.
[    4.585328] microcode: You should switch to early loading, if possible.
[    4.595459] microcode: updated to revision 0x17, date = 2023-12-07
[    4.602552] microcode: Reload succeeded, microcode revision: 0xe -> 0x17

brada4 · February 22, 2025, 1:55pm

It applies only to "caveat" microcode that is usually thrown in initrd.

brada4 · February 23, 2025, 2:25pm

Support was there for one day.

darksky · February 23, 2025, 2:56pm

Nice find @brada4 - no reason given for revert

brada4 · February 23, 2025, 3:24pm

But at least gives the idea what to do.

darksky · February 23, 2025, 3:31pm

I agree, just wondering if there was some deleterious effects from enabling it.

lleachii · February 23, 2025, 4:47pm

Tagging: @blogic

dave14305 · March 9, 2025, 10:45am

https://lists.openwrt.org/pipermail/openwrt-devel/2018-November/020431.html

Seems steps have been taken since:

github.com/openwrt/openwrt

x86: add bootloader upgrade on sysupgrade

committed 08:36PM - 01 Mar 20 UTC

tmn505

+33 -3

Currently bootloader always stays on the same version as when first written to b…oot medium (not true if partition layout changed, which will trigger sysupgrade process to write full disk image). That creates inconveniences as it always stays with same features or/and bugs. Users wishing to add support to additional modules or new version, would need to write the whole image, potentially destroying previous system configuration. To fix these, this commit adds additional routine to sysupgrade which upgrades unconditionally the bootloader to the latest state provided by OpenWrt. Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>

github.com/openwrt/openwrt

grub2: re-add test module

committed 09:22PM - 26 Feb 23 UTC

tmn505

+3 -3

It seems more hardware needs early load of firmware when initialised to work pro…perly (at least Intel hardware). One of previous case is CPU microcode, which this series[1] tried to change. The second one is Intel graphics IC, which needs firmware for controlling DMC circuit (switch conncted display to DC6 power state). As it stands, the i915 module is built-in and it seems the hardware can't cope with firmware loaded later from rootfs, it needs to be supplied when the module is loaded. Unfortunately we need bootloader to handle the load of firmware in this case, but as previously mentioned series[1], there was an error when initrd was hardcoded, instead of testing existence for it and then loading. To remedy this in later the 55b808e0c4be ('x86: image: add test module to bootloader') was commited. Which was later accidentally dropped when grub2 image creation was moved to packages. Therefore bring back test module, so we can test for cases of existing firmware in grub.cfg. 1. https://patchwork.ozlabs.org/project/openwrt/cover/20181120162044.16371-1-tomek_n@o2.pl Fixes: 5a5df62d95f5 ("x86/grub2: move grub2 image creation to package") Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>

Ping @tmn505 for feedback.

darksky · March 9, 2025, 12:42pm

Nice find @dave14305 - it seems the issue in keeping this back in 2018 was on a sysupgrade, grub would not get updated and thus fail due to the missing test module. It seems that that module has been added in early 2023 with bdd78897c33b25a4954f6e41e26f57bab5284129

I wonder if that is sufficient time to assume it is present and allow the early loading code to be merged.

I created a draft PR due to the fact that /boot/amd-ucode.img that it creates doesn't actually update on my test machine whereas replacing it with the version built in the Arch Linux amd-ucode package does. If anyone has any insights, I am interested to here them!

github.com/openwrt/openwrt

x86: enable early loading of firmware for amd/intel

main ← graysky2:early-ucode

opened 01:09PM - 09 Mar 25 UTC

graysky2

+34 -16

This is an attempt to resurrect some work by others circa 2018 to enable firmwar…e early loading for x86. Late loading has be deprecated upstream with Linux 5.19 (June 2022). See [kernel docs](https://www.kernelconfig.io/config_microcode_late_loading) for more. One issue I am finding with the PR as-is is that the way this generates `/boot/amd-ucode.img` does not get applied when booting. For example, after booting on my test system (AMD Ryzen 7 8845HS). ``` # dmesg | grep micro [ 6.018646] microcode: CPU1: patch_level=0x0a705203 [ 6.018654] microcode: CPU13: patch_level=0x0a705203 [ 6.018654] microcode: CPU9: patch_level=0x0a705203 [ 6.018659] microcode: CPU0: patch_level=0x0a705203 [ 6.018659] microcode: CPU8: patch_level=0x0a705203 [ 6.018662] microcode: CPU7: patch_level=0x0a705203 [ 6.018666] microcode: CPU4: patch_level=0x0a705203 [ 6.018666] microcode: CPU12: patch_level=0x0a705203 [ 6.018667] microcode: CPU6: patch_level=0x0a705203 [ 6.018673] microcode: CPU2: patch_level=0x0a705203 [ 6.018673] microcode: CPU10: patch_level=0x0a705203 [ 6.018675] microcode: CPU11: patch_level=0x0a705203 [ 6.018689] microcode: CPU5: patch_level=0x0a705203 [ 6.018690] microcode: CPU14: patch_level=0x0a705203 [ 6.018709] microcode: CPU15: patch_level=0x0a705203 [ 6.018728] microcode: CPU3: patch_level=0x0a705203 [ 6.108237] microcode: Microcode Update Driver: v2.2. ``` Yet if I boot the same machine using `amd-ucode.img` copied over from Arch Linux's package: ``` # dmesg | grep micro [ 6.027058] microcode: microcode updated early to new patch_level=0x0a705206 [ 6.035089] microcode: CPU3: patch_level=0x0a705206 [ 6.035092] microcode: CPU5: patch_level=0x0a705206 [ 6.035094] microcode: CPU11: patch_level=0x0a705206 [ 6.035115] microcode: CPU0: patch_level=0x0a705206 [ 6.035115] microcode: CPU8: patch_level=0x0a705206 [ 6.035116] microcode: CPU9: patch_level=0x0a705206 [ 6.035116] microcode: CPU1: patch_level=0x0a705206 [ 6.035118] microcode: CPU10: patch_level=0x0a705206 [ 6.035119] microcode: CPU12: patch_level=0x0a705206 [ 6.035120] microcode: CPU6: patch_level=0x0a705206 [ 6.035121] microcode: CPU15: patch_level=0x0a705206 [ 6.035096] microcode: CPU13: patch_level=0x0a705206 [ 6.035447] microcode: CPU5: new patch_level=0x0a705206 [ 6.035473] microcode: CPU10: new patch_level=0x0a705206 [ 6.035476] microcode: CPU12: new patch_level=0x0a705206 [ 6.035485] microcode: CPU6: new patch_level=0x0a705206 [ 6.035486] microcode: CPU15: new patch_level=0x0a705206 [ 6.035519] microcode: CPU4: patch_level=0x0a705206 [ 6.035519] microcode: CPU14: patch_level=0x0a705206 [ 6.035523] microcode: CPU2: patch_level=0x0a705206 [ 6.035550] microcode: CPU7: patch_level=0x0a705206 [ 6.035798] microcode: CPU13: new patch_level=0x0a705206 [ 6.035818] microcode: CPU0: new patch_level=0x0a705206 [ 6.035818] microcode: CPU8: new patch_level=0x0a705206 [ 6.035820] microcode: CPU9: new patch_level=0x0a705206 [ 6.035820] microcode: CPU1: new patch_level=0x0a705206 [ 6.035867] microcode: CPU4: new patch_level=0x0a705206 [ 6.035868] microcode: CPU14: new patch_level=0x0a705206 [ 6.035874] microcode: CPU2: new patch_level=0x0a705206 [ 6.035899] microcode: CPU7: new patch_level=0x0a705206 [ 6.040687] microcode: CPU3: new patch_level=0x0a705206 [ 6.046290] microcode: CPU11: new patch_level=0x0a705206 [ 6.057308] microcode: Microcode Update Driver: v2.2. ```

dave14305 · March 9, 2025, 3:24pm

I don’t know anything about how the image file is supposed to be created, but I’m puzzled a bit by the concatenation of all the files. My only other reference for such an initrd is here:

Edit: I see the same approach used in the Arch Linux build, so maybe I’m not helping here.

Edit2: what directory structure ends up inside the archive? Does it need to be /lib/firmware/ inside?