From ArchWiki
Jump to navigation Jump to search

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)
I believe your confirmation was for the general EFISTUB content, but not the disputed content. The dispute should stand.
Thesqueakychair (talk) 02:23, 14 August 2019 (UTC)

This content links to the systemd-boot page. The snippet refers to a snippet on that page. Nothing in this content relates to EFISTUB, so I moved it into systemd-boot section. I originally hoped to remove this 1 year stale, 3 year old dispute, but I don't know anything about systemd-boot, secure boot, or signed kernels. So this dispute stands... Thesqueakychair (talk) 02:23, 14 August 2019 (UTC)

So how can I help to resolve this dispute? Yes, I used the linked page from systemd-boot to generate the mentioned bundled kernel. Then I wondered how to get microcode into this bundle as well. It took me quite long to find the answer (which is "use cat"), so I wanted to document it here. If you deem it unhelpful, confusing, wrong or similar, feel free to remove it or put it somewhere else. I agree that putting it to systemd-boot is the better place although the linked page has already been marked as "does not belong here" and my boot-setup doesn't use this mentioned /boot/loader/entries/entry.conf file at all. I am happy to give more information on it but I don't see any questions remaining at the moment. Aliena 08:36, 20 September 2019 (UTC)

I think this can be simply solved by moving the instructions to a separate section, e.g. "Unified kernel image"[1].
Arguably Systemd-boot#Preparing kernels for /EFI/Linux and similar stuff littered throughout the wiki (not the contents of Microcode though) should all be placed in a dedicated "Unified kernel image" article.
-- nl6720 (talk) 09:52, 21 September 2019 (UTC)

My opinion is that the section definitely belongs in the systemd-boot page. "/EFI/Linux is searched for specially prepared kernel files". Yes, by systemd-boot. Systemd-boot also parses the single file, and adds to systemd-boot's menu based on the embedded os-release file. The specially prepared kernel file is a way to embed the configuration and the files the configuration refers to, as described in "Adding loaders" into a single file. These two ways are just the functionally equivalent "Type #1" and "Type #2" boot loader entries described in the Boot Loader Specification. I don't think the Preparing Kernels for /EFI/Linux section should be moved to another page, but should be presented as an alternative to the Adding Loaders subsection. An introduction should also be added, telling these are the two alternate ways of adding a Linux entry to the menu.

-- jmyreen 19:30, 14 January 2020 (UTC)
I don't think that the fact that systemd-boot searches for the unified kernel images is a good enough reason to keep the section in systemd-boot, but the fact that a part of systemd-boot is used to create those EFI binaries IMHO is.
I renamed the section in systemd-boot to include the term "unified kernel image" and mode the disputed part of Microcode into a subsection of Microcode#systemd-boot: Microcode#Unified kernel images. I think that, for now, this should solves the current issues.
-- nl6720 (talk) 11:36, 15 January 2020 (UTC)

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 ~~~~!