FS#42354 - [grub] requires changes for ucode loading

Attached to Project: Arch Linux
Opened by Christian Hesse (eworm) - Monday, 13 October 2014, 10:58 GMT
Last edited by Ronald van Haren (pressh) - Monday, 10 November 2014, 15:30 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Ronald van Haren (pressh)
Architecture All
Severity Medium
Priority Urgent
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 44
Private No

Details

Description:
Starting with latest linux and intel-ucode packages Intel microcode needs to be loaded early [0]. Grub has to handle this.

I have created a simple patch that works for me, though this may have some rough edges.

[0] https://lists.archlinux.org/pipermail/arch-dev-public/2014-October/026690.html

Additional info:
linux 3.17-2
intel-ucode 20140913-1
grub 1:2.02.beta2-4
This task depends upon

Closed by  Ronald van Haren (pressh)
Monday, 10 November 2014, 15:30 GMT
Reason for closing:  Implemented
Additional comments about closing:  1:2.02.beta2-5
Comment by Florian W. (w-flo) - Wednesday, 22 October 2014, 22:54 GMT
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
Comment by Mike Cloaked (mcloaked) - Thursday, 23 October 2014, 07:31 GMT
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?
Comment by Florian W. (w-flo) - Thursday, 23 October 2014, 21:08 GMT
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.
Comment by Mike Cloaked (mcloaked) - Thursday, 23 October 2014, 21:27 GMT
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.
Comment by Ronald van Haren (pressh) - Sunday, 26 October 2014, 13:14 GMT
I'll get to this tomorrow
Comment by tj (firekage) - Sunday, 26 October 2014, 15:18 GMT
Sorry for stupid question, but i never knew how to do this kind of work. Could somebody write how to apply this patch?
Comment by David Kowis (BeepDog) - Monday, 27 October 2014, 02:32 GMT
Is it possible to have it work like a module during mkinitcpio ?
Comment by Christian Hesse (eworm) - Monday, 27 October 2014, 08:56 GMT
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.
Comment by Christian Hesse (eworm) - Monday, 27 October 2014, 08:59 GMT
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.
Comment by Christian Hesse (eworm) - Monday, 27 October 2014, 09:13 GMT
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...
Comment by Christian Hesse (eworm) - Monday, 27 October 2014, 09:17 GMT
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?
Comment by Marcel Korpel (Marcel-) - Monday, 27 October 2014, 13:21 GMT
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).
Comment by Mike Cloaked (mcloaked) - Monday, 27 October 2014, 16:45 GMT
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.
Comment by Christian Hesse (eworm) - Monday, 27 October 2014, 17:03 GMT
% 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...
Comment by Marti (intgr) - Monday, 27 October 2014, 17:26 GMT
> 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.
Comment by Christian Hesse (eworm) - Monday, 27 October 2014, 19:13 GMT
> 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?
Comment by Marti (intgr) - Tuesday, 28 October 2014, 00:51 GMT
> Tested that, does not work...

Oh :( Sorry.

Is it deliberately made that way, or perhaps just a bug in the early microcode loading?
Comment by John (graysky) - Saturday, 01 November 2014, 13:38 GMT

Loading...