Talk:Microcode

Which CPUs accept microcode updates

AMD has closed its Operating System Research Center since November 2012: See this Phoronix article

The link to AMD's Operating System Research Center doesn't work any longer.

Maybe the section should be updated by removing the information for AMD users and keep only the information for Intel users ?

—This unsigned comment is by Zzrzlk (talk) 08:53, 1 July 2019‎ (UTC). Please sign your posts with ~~~~!

Grub config file instructs the user not to manually edit it.

It might be worth making some kind of note that grub does not expect users to be editing the config file since the wiki presents manually editing this file as an option.

Benm (talk) 22:43, 27 March 2021 (UTC)

It specifically says that option is for people managing the config file manually instead of using grub-mkconfig. It's a completely different situation from what you're talking about.

Scimmia (talk) 23:08, 27 March 2021 (UTC)

Reverting Unified kernel images section to pre Special:Diff/751285

Reverted the Unified kernel images subsection to before Special:Diff/751285, as it just duplicates content which is already in Unified kernel image#mkinitpcio, whereas Unified kernel image contains guidance for mkinitcpio and other methods.

-- Cvlc (talk) 16:50, 5 October 2022 (UTC)

microcode hook in mkinicpio

/etc/mkinitcpio.conf ships with the hook microcode now. Would be nice to have some information here about what it does or where to find more information. Pavelskipenes (talk) 18:41, 4 March 2024 (UTC)

https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_requests/291 Hanabishi (talk) 19:03, 4 March 2024 (UTC)

I get the impression that I have to

1. Remove `amd-ucode` or `intel-ucode` from bootloader's initrd.
2. Add `microcode` to mkinitcpio's hooks.

Is that right? I haven't done anything because I don't want to mess up. I wish the wiki could make it more clear. 4color (talk) 02:44, 6 March 2024 (UTC)

The `microcode` hook is automatically added to `/etc/mkinitcpio.conf` after new initramfs update. So I think we should only remove ucode from bootloader's initrd and nothing else. (Second step you mentioned is already done automatically) Jtag (talk) 11:23, 6 March 2024 (UTC)

It is added automatically, but if the user modified `/etc/mkiniticpio.conf` in the past, the change is only done to the Pacnew file and has to be merged manually. The creation of the Pacnew file is also mentioned in the pacman log. Gregthwuen (talk) 13:22, 9 March 2024 (UTC)

Yes very important note, thanks for mentioning. Jtag (talk) 12:03, 15 March 2024 (UTC)

You also have to run mkinitcpio again to regenerate the images. But I think this isn't enough because with the changes it's not generating /boot/xxx-ucode.img and apparently no microcode is being loaded as I'm seeing warnings on journalctl. Danisztls (talk) 11:13, 15 March 2024 (UTC)

It is working. The warning always existed. Danisztls (talk) 14:55, 29 April 2024 (UTC)

What I'm also wondering is whether the `amd-ucode` and `intel-ucode` packages are still required after this change. At least the `.img` files in `/boot/` shouldn't be necessary anymore, right? Gregthwuen (talk) 13:33, 9 March 2024 (UTC)

Of course. They contain the microcode in /usr/lib/firmware [1], which is used by mkinitcpio.

Hanabishi (talk) 14:15, 9 March 2024 (UTC)

You mean `amd-ucode` and `intel-ucode` packages are still required, or the `.img` files in `/boot/` aren't necessary anymore, or both? 4color (talk) 14:26, 9 March 2024 (UTC)

Both. If you use mkinitcpio with the new microcode hook, you don't need imgs anymore. You could delete them manually, but they will be installed again with the next firmware update anyway, so it is kinda pointless.

Answering ahead of the next question: old images are kept for compatibility [2].

Hanabishi (talk) 14:36, 9 March 2024 (UTC)

Thanks for clarifying. For other hooks mkinitcpio prints out a warning about “possibly missing” files, which does not happen for the `microcode` hook with the `-ucode` packages missing. That's what irritated me a bit. Gregthwuen (talk) 15:33, 9 March 2024 (UTC)

I went down the rabbit hole, yes - and the bit of missing information from the announcement is a step found in the forums after:

1. Update all packages
2. Add `microcode` to mkinitcpio's hooks
3. Regenerate all initrds

   1. mkinitcpio -p linux

   2. mkinitcpio -p linux-lts

4. Add to `/etc/default/grub`:

   1. GRUB_EARLY_INITRD_LINUX_STOCK=""

5. Regenerate grub.cfg (keep an old copy! you can rescue boot it)

   1. cp -a /boot/grub/grub.cfg /boot/grub/grub-old.cfg

   2. grub-mkconfig -o /boot/grub/grub.cfg

Under the hood, the intel/amd packages own both the pre-built /boot img files and the unpacked files in /lib/firmware. The new mkinitcpio code runs a CPU detection routine, then takes the unpacked files and builds it's own combined binary ("GenuineIntel.bin" e.g.) which is then added inside the initramfs file. (run mkinitcpio --verbose .... > log.txt to see it all, it's a lot of output)

So for now due to how the packaging is combined for ucode, we have to use that extra setting to tell GRUB to ignore those files on disk as part of it's auto-detection routines. It's documented about 1/2 the way down the manual over here: https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html TE (talk) 14:26, 9 March 2024 (UTC)

Is using the new microcode hook actually manadatory in all cases going forward, or just for the subset of users that were previously relying on the --microcode flag and the microcode option in the preset files?

If you're using GRUB you can just skip adding the microcode hook and microcode loading is still going to work. In this case there is no need to add GRUB_EARLY_INITRD_LINUX_STOCK="" to /etc/default/grub. That's what I did since it seemed the more straightforward solution given the (lack of) information in the news. Noctavian (talk) 16:10, 12 March 2024 (UTC)

No, not mandatory. You can remove the hook and continue to use separate .img files the old way.

In fact mkinitcpio is very late with this trasnition. E.g. dracut includes microcode into the initrd image already for years.

Hanabishi (talk) 16:19, 12 March 2024 (UTC)

Noctavian your question is also "how far do I want to drift from the Arch desired defaults?" as well. The updated mkinitcpio package deploys the microcode hook in the default config file, making it an expected part of a "normal" system going forward. You needn't have ever used any special work before such as a --microcode switch, it was all being done for you by the GRUB logic and ucode packages working in tandem.

The updated GRUB work is nothing more than "don't have two subsystems trying to do the same thing" (inject microcode), it's left in place right now for compatibility needs; I can envision a future where the `intel-ucode` (and amd) packages stop deploying the file /boot/intel-ucode.img which will naturally stop GRUB from adding it as an initrd without any config actions needed. But that day may be far down the road (who knows), by doing this work now I ensure my desired outcome is met. $0.02 TE (talk) 18:37, 12 March 2024 (UTC)

Is there any discussion or justification for why this change was made in mkinitcpio? I've been familiar with dracut for a while and understood this microcode loading method to be implemented there only for some legacy compatibility reason, and that loading microcode as a separate initrd was the superior option, if supported. Brocellous (talk) 20:00, 13 March 2024 (UTC)

You might find something in the discussion around the relevant merge request. Do you have some reference for this dracut reasoning? — Lahwaacz (talk) 22:31, 13 March 2024 (UTC)

I doubt that information too. At least because dracut worked that way since the very introduction of microcode loading support [3]. And even mere awareness of existing images was introduced far later [4].

Hanabishi (talk) 23:11, 13 March 2024 (UTC)

Sorry, no reference. I learned this idea from an old coworker and don't know where it came from. I also didn't see anything about the motivation for the change in the merge-request.

Here's my understanding:

At some point linux added support for early microcode loading, and shortly thereafter dracut added support for the same. Linux can load multiple initrds, but for whatever reason (possibly compat with older GRUB or linux?) dracut chose to pack the ucode into the beginning of the primary initramfs image. For bootloaders the "modern" strategy for loading initrd, introduced later than the dracut hack, is UEFI EFI_LOADED_IMAGE_PROTOCOL with LINUX_EFI_INITRD_MEDIA_GUID. It is arch agnostic and so the preferred method in both systemd-boot and GRUB (?). To linux, IIUC, with this method the two initrd look the same as the dracut hack since the initrd are just smooshed together when loaded. So the dracut hack is just an extra unnecessary complication with no benefit. If anything, dracut should have dropped this old hack but never did.

With that context, I'm very confused why mkinitcpio chose to adopt this behavior. Do you know if there is any error in my understanding? Is there another reason that it is desirable to have the microcode and initramfs in the same file? Because otherwise it seems easier and more explicit to just specify the ucode and initramfs directly and independently. Brocellous (talk) 00:03, 23 April 2024 (UTC)

Your understanding is wrong. Images don't exist in the first place, they are distro-specific. Microcode is delivered by upstreams as regular firmware blobs (i.e. as files in /usr/lib/firmware/).

In Arch, images are generated artifically during packaging [5] [6]. So it is quite the opposite to your statement, building the images is actually an extra unnecessary step. Microcode blobs can simply be copied into the main initrd image along with other regular firmware blobs and kernel modules in a generalized way, they are not that special really.

Hanabishi (talk) 00:36, 23 April 2024 (UTC)

Sorry, you're wrong.

Yes, the cpio images shipped in the repos are generated at packaging time. With the mkinitpcio changes, the _same_ cpio image is generated along with the primary initramfs on the client, and is prepended to the initramfs. Once loaded, this looks exactly the same as if the bootloader had just loaded two initrds from two files, just mkinitcpio has concatenated them ahead of time.

The microcode _is_ special. It to be before the compressed initramfs image or the kernel will not see it, which is why it is _not_ placed in the initramfs along with the other regular firmware blobs. Brocellous (talk) 01:24, 23 April 2024 (UTC)

I wouldn't call squashing the files via cat something special. It is not like some complicated processing happening there. No long compilation etc. that can justify shipping prebuilt images.

But anyway, what is the benifit of having them in a separate images? I.e. why have multiple images when you can have a single one?

Also this way allows to include only certain microcode files for your CPU model only. And mkinitcpio hook does that in autodetect mode.

Hanabishi (talk) 01:43, 23 April 2024 (UTC)

If I had to guess, the packed microcode+initramfs is preferred for use with UKI, since there was only one .initrd section to be used.

But this has since been rectified: https://github.com/uapi-group/specifications/pull/98 Brocellous (talk) 01:30, 23 April 2024 (UTC)