Talk:Microcode

From ArchWiki
Jump to navigation Jump to search

CPU microcode loading support for custom kernel

Is the section Microcode#Enabling Intel Early Microcode Loading in Custom Kernels still relevant when initrd /intel-ucode.img is added to the Gummiboot options? -- Gim (talk) 09:42, 1 November 2014 (UTC)

Passing parameters with refind

With this edit User:Vesz deleted "/boot/" from parameters. Is this correct? Because in the following paragraph there is explained to use initrd=/intel-ucode.img or /boot/intel-ucode.img as required. As you can see, there "/" symbol is used before "intel-ucode.img". — Agent0 (talk|contribs) 20:21, 20 February 2015 (UTC)

I have only tried using it without a /, and it works. I assume that it might work with a / as well but I haven't confirmed it. Either way it seems that if you have a separate boot partition it's wrong to enter the path in a root-filesystem format. I don't have access to the system in question right now so I can't try with a leading /. Vesz 21:09, 20 February 2015 (UTC)

Addition in EFI Boot stub

My addition to the Microcode#EFI_boot_stub_.2F_EFI_handover refers to use cases where the kernel and initrd are merged into a single .efi file, which can be signed for secure boot. In that case you can only specify a single initrd. If you want to update the microcode anyway in this setup, the microcode and the actual initrd can be concatenated with cat. --Aliena 27.05.2017 20:07

Thank you for responding to this, better late then never. However, that still does not explain why the single .efi file is necessary (initrd is not mentioned even once on the Secure Boot page), nor what objcopy ... is supposed to do. It also does not seem specific to the "EFI boot stub / EFI handover" section. -- Lahwaacz (talk) 19:37, 27 May 2017 (UTC)
I'm only learning how to care of contributions, i.e. having a watchlist etc. objcopy is not mentioned directly, but the Secure Boot page refers to sbupdate-gitAUR which uses it to generate a single .efi file. There is also this github repo which has a script to do the same job. This setup is desirable because this way kernel, initrd and cmdline are protected by secure boot. This is a special application of the EFI boot stub since that stub is used as a "base binary" in objcopy to generate the singed kernel binary. Thus I added it to the section rather than creating an own one. And when using this objcopy tool to solve the problem of securing the initrd you can only integrate a single initrd. Now the question my post answers is: "How can I use objcopy to have the microcode loaded before the actual initrd?" and the anser is "Concatenate them". Aliena 17:20, 28 May 2017 (UTC)
I can confirm that this is indeed valid. I am using a pure EFI boot stub i.e. no .efi boot loader and the initrd list is specified directly in UEFI. From efibootmgr --unicode --verbose:
Boot0000* Arch Linux    HD(1,GPT,5ebe91b3-136f-4355-b237-99367797f87e,0x800,0x100000)/File(\vmlinuz-linux)initrd=\amd-ucode.img initrd=\initramfs-linux.img root=UUID=107705cf-5290-4660-9a15-2714b9e36da7 rootflags=subvol=/@root rw
Let's remove this dispute from the page.
Alex-courtis (talk) 07:57, 3 October 2018 (UTC)

"concatenated on top" is confusing

This text is confusing, to me:

Note: The order is important. The original image initramfs-linux.img must be concatenated on top of the cpu_manufacturer-ucode.img image.

But since the following command is also there, I understood what it meant:

# cat /boot/cpu_manufacturer-ucode.img /boot/initramfs-linux.img > /boot/initramfs-merged.img

So, append initramfs image file contents after the microcode contents, in a new output file. Or, make sure the microcode is prepended at the beginning of the initramfs image. Or, initramfs image is concatenated at the end of microcode image. Or just concat microcode and initramfs images, in that order.

Howaboutsynergy (talk) 11:48, 11 May 2019 (UTC)

I've found another use of `concatenated on top of` to mean `appended to` in Linux Kernel's Documentation/acpi/initrd_table_override.txt
# The uncompressed cpio archive must be the first. Other, typically                                                             
# compressed cpio archives, must be concatenated on top of the uncompressed
# one. Following command creates the uncompressed cpio archive and
# concatenates the original initrd on top:
find kernel | cpio -H newc --create > /boot/instrumented_initrd
cat /boot/initrd >>/boot/instrumented_initrd
So, then I must be the only one who's confused by that expression ... mainly because I think of what they mean 'top' as the 'end'/'bottom' of the file instead of what I'd normally consider 'top' which would be the beginning of the file at offset 0.
Howaboutsynergy (talk) 00:10, 13 May 2019 (UTC)
You're not the only one confused by that phrase. I don't see a point in thinking about files in such terms. How about changing the note to:
Note: The order is important. The original image initramfs-linux.img must be placed after cpu_manufacturer-ucode.img in the resulting image.
-- nl6720 (talk) 08:53, 13 May 2019 (UTC)
Sounds good to me. 👍 Howaboutsynergy (talk) 12:51, 13 May 2019 (UTC)
Since there were no objections, I updated the text. -- nl6720 (talk) 11:58, 20 May 2019 (UTC)