Arch Linux

Proposed patch content manually copy-pasted into my installed /etc/…/10_linux file works for me (Ivy Bridge):

# grub-mkconfig -o /boot/grub/grub.cfg
[…]
Found Intel Microcode image
Linux-Abbild gefunden: /boot/vmlinuz-linux
initrd-Abbild gefunden: /boot/initramfs-linux.img
Found fallback initramfs image: /boot/initramfs-linux-fallback.img

After reboot:
# journalctl -b | grep early
Okt 23 00:47:28 zbox kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29
Okt 23 00:47:28 zbox kernel: CPU1 microcode updated early to revision 0x1b, date = 2014-05-29

Would it not be the case that if this had updated to the current version it would be more recent than 2014-05-29 or is this before the update to the new version of intel-ucode?

I think I was using the latest intel-ucode package at boot time. Maybe my Ivy Bridge CPU still needs 0x1b instead of 0x1c. Or something is wrong with my setup. Anyway, grub successfully booted the initrd to update microcode, so this bug is fixed by applying the patch from my POV.

I have done further testing and on my Ivybridge machine I also have the intel version date as 2014-05-29 for early microcode loading with the latest current kernel and intel-ucode packages, so it looks like that was indeed the correct latest version 0x1b. I also have a Haswell laptop which has a later version date for the early microcode load as 2014-07-03 so it depends on which CPU is involved. So I agree with your conclusion.

I'll get to this tomorrow

Sorry for stupid question, but i never knew how to do this kind of work. Could somebody write how to apply this patch?

Is it possible to have it work like a module during mkinitcpio ?

No, that is too late. Inside the initramfs we have not yet entered main system, but it's userspace already and updating microcode would crash the kernel.

Thinking about this... I have in mind that a single initramfs file can contain more than one cpio image. Can not find the documentation about that, though. Anybody with a hint? :D
Possibly we can make mkinicpio write the needed microcode and padding, then create the "real" initramfs appended to that.

Just found this...
https://www.kernel.org/doc/Documentation/x86/early-microcode.txt

Not sure if it suits our needs or if it is too late already.

Looking at the intel-ucode format this may have the correct format already:

# lsinitcpio /boot/intel-ucode.img
kernel/x86/microcode/GenuineIntel.bin

Possibly we should leave all boot loaders as-is and change mkinitcpio to concatenate the Intel and/or AMD microcode image and the generated initramfs. Will test this...

Looks good I think. :D

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

Then make grub boot the new file (ucode-initramfs-linux.img) instead of the default one. Works perfectly for me, microcode is successfully updated to 0x1b. (I do not have a CPU that makes the kernel crash, though.) Anybody else wants to try?

Works correctly for me:

$ dmesg|grep microcode
[ 0.000000] CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28
[ 0.006666] CPU1 microcode updated early to revision 0xa0b, date = 2010-09-28

About the patch: I don't use grub-mkconfig, I always manually changed my grub.cfg, generated by the grub1→grub2 converter (I just never got used to grub2's syntax).

Just out of interest of you make a combined initrd file as per eworm's comment and the file is called /boot/ucode-initramfs-linux.img then what does the output of lsinitcpio /boot/ucode-initramfs-linux.img look like?

I think this will only see kernel/x86/microcode/GenuineIntel.bin and not the main initial ramdisk file.

% lsinitcpio -l /boot/initramfs-linux.img
kernel/x86/microcode/GenuineIntel.bin

It only reads the first archive. So we need some changes to lsinitcpio as well...

> It only reads the first archive. So we need some changes to lsinitcpio as well...

Huh? Clearly the "right" solution is to put the GenuineIntel.bin file to the right location in our main initramfs image, instead of concatenation tricks or loading multiple initrd images.

> Huh? Clearly the "right" solution is to put the GenuineIntel.bin file to the right location in our main initramfs image, instead of concatenation tricks or loading multiple initrd images.

Tested that, does not work... Or can you prove it works?

> Tested that, does not work...

Oh :( Sorry.

Is it deliberately made that way, or perhaps just a bug in the early microcode loading?

https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/grub&id=e9986fb7c29be259e680b91a3732f1a12dbf02b7