Talk:Unified Extensible Firmware Interface/Secure Boot

From ArchWiki
Jump to navigation Jump to search

Enroll hash file name

I am a bit confused regarding the following lines:

* In the HashTool main menu, select Enroll Hash, choose \loader.efi and confirm with Yes. Again, select Enroll Hash and archiso to enter the archiso directory, then select vmlinuz-efi and confirm with Yes. Then choose Exit to return to the boot device selection menu.

  • In the boot device selection menu choose Arch Linux archiso x86_64 UEFI CD

There is no file vmlinuz-efi in the said directory, there is only efiboot.img. Then, the USB stick actually wants to boot from arch/boot/x86_64/vmlinuz. I am not sure which file I actually had to enroll, it was either archiso.img in that directory or the vmlinuz kernel image. In either case the instruction is not accurate. --Johannes Rohr (talk) 09:03, 5 February 2015 (UTC)

Indeed the instructions are not accurate, and are only meant as an outline. The thing is that their accuracy depends on the approach chosen. For example, the article suggests, among other approaches, to disable secure boot altogether. I think one is expected to integrate the outline in booting archiso with one of the approaches suggested by the rest of the article. For example, the Set up PreLoader section explicitly states the usefulness of PreLoader.efi and HashTool.efi in efitools is limited. But it also suggest how to get along with PreLoader.efi and HashTool.efi from preloader-signedAUR or to download them manually without using the AUR. Regid (talk) 02:05, 18 December 2018 (UTC)
The comment you're replying to is from a time when the Archiso supported Secure Boot. -- nl6720 (talk) 09:34, 18 December 2018 (UTC)
  1. Why, and when, support for secure boot removed from Archiso?
  2. I find the article confusing. Most of it assumes users are able to install software on the machine, and copy files from anyplace to anywhere on the HD. As if they have a running archlinux installation, and only need to convert the boot process into secure boot. But installation is different. I think the booting archiso section should be moved to the section that is prior to see also; emphasize that there is a need to create files and than place them on the EFI system partition; point to archiso and Remastering the Install ISO; and reworked in general.
Regid (talk) 10:59, 18 December 2018 (UTC)
As it says in Secure Boot#Booting archiso, Secure Boot support was removed starting with archlinux-2016.06.01-dual.iso. It happened because an Arch developer replaced[1][2] the prebootloader package with the efitools package. Apparently it happened because both contain PreLoader.efi and HashTool.efi. The little detail that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[3]. -- nl6720 (talk) 11:15, 18 December 2018 (UTC)
Regarding your "2." point. The simple method is to disable Secure Boot, install Arch Linux, setup and enable Secure Boot. The Template:Out of date is there because you can't boot the official install media with Secure Boot enabled. If you want to add instructions on remastering Archiso with Secure Boot support, go ahead. -- nl6720 (talk) 11:18, 18 December 2018 (UTC)
+1 to the simple method regarding section organization. @Regid: I get what you meant about the template and instruction-flow. Still, I find the current organization even more confusing. Now, the first link goes to Secure Boot#Put firmware in "Setup Mode", jumping over all the steps that must be understood/done. The last thing someone must do is to remove a platform key from the UEFI before there is an installable ISO. -- Indigo (talk) 20:31, 18 December 2018 (UTC)
I have edited the article to address Indigo comment. Regid (talk) 11:43, 19 December 2018 (UTC)
Thanks, IMO it's better like this for now. Something the article still needs is a little more intro how to proceed for either of the major sections. My suggestion for it is to do it in the [4] (better idea? change it). I realize that "Change the status" is not an ideal subsection title, but it should give an idea what's missing in my view. An alternative would be to put it into the article intro with 2-3 sentences. --Indigo (talk) 19:15, 20 December 2018 (UTC)

Move to "Unified Extensible Firmware Interface/Secure Boot"

Secure Boot is a feature of UEFI, so the correct place for Secure Boot article would be under Unified Extensible Firmware Interface: Unified Extensible Firmware Interface/Secure Boot. –– nl6720talk 16:36, 14 August 2016 (UTC)

While it is true Secure Boot is a UEFI feature, the new name is too long. So I vote for just keep its current name. --Fengchao (talk) 05:09, 25 August 2016 (UTC)
The name length shouldn't really matter, we could use UEFI/Secure Boot (with redirect) to reference it in other articles. The point of the move is to put Secure Boot in its proper place. -- nl6720talk 11:30, 25 August 2016 (UTC)
Agree for better organization. --Franklin Yu (talk) 03:09, 24 May 2017 (UTC)
No. It's a separate security feature with PKI, which is pretty tedious to properly set up (creating keys, single EFI image, LVM on LUKS, messing with /boot etc), so SB section tends to be bigger than whole UEFI article. Main UEFI article may contain instruction how to disable it and redirect here for those who motivated enough to avoid multiple security pitfails. - Radioxoma (talk) 15:26, 30 November 2019 (UTC)
The page has been moved, close. -- Blackteahamburger (talk) 10:09, 2 June 2020 (UTC)


I couldn't add anything to MoKList on my real PC, but everything worked in qemu; it could use more testing. The instructions should theoretically work for rEFInd and GRUB. AFAIK systemd-boot doesn't support shim and trying to launch SYSLINUX resulted in "System is compromised. halting.".

The instruction are for a generic bootloader because I have no interest in installing GRUB, and adding instructions for rEFInd would be pointless since rEFInd has a really simple setup for shim refind-install --shim /usr/share/shim-signed/shim.efi for hash only and refind-install --shim /usr/share/shim-signed/shim.efi --localkeys for hash and keys. If anyone is willing to rewrite the instructions to use GRUB as the example bootloader, please do. -- nl6720 (talk) 13:02, 7 December 2016 (UTC)

A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. UBF6 (talk) 14:40, 8 November 2018 (UTC)

systemd-boot efi binary signature incomplete

It looks like "Signing kernel with pacman hook" section has to be completed with systemd-boot binary signing with something like sbsign --cert <cert> --key <key> --output

Unb0rn (talk) 16:19, 3 March 2019 (UTC)

Hi Unb0rn. I'm the author of that article section. I don't understand. This is exactly what I have written in the hook. If you watch closely, at the end of the oneliner, sbsign is being called properly. Could you precise what you mean by the need of completeness? -- wget (talk) 21:56, 28 April 2019 (UTC)

add section explaining the signing of other EFI utilities, or general troubleshooting section

I'd like to propose adding a section that explains the signing of other EFI utilities such as those detailed on

In particular I've just recently resolved an issue which I'm guessing is specific to my motherboard (ASrock Z77 Extreme4) that I'd like to add some troubleshooting info on. Specifically the gdisk_x64.efi image is shipped signed with the author's key, and apparently my bios only looks at the first key signature of a given EFI app. By removing the author's signature with sbattach --remove gdisk_x64.efi I was finally able to get it to run with Secure Boot enabled.

Or maybe this would be better added to a general troubleshooting section? I haven't tested it but I bet if I first signed *any* EFI app with some key that isn't enrolled on my system, and then added my own, I'd have the same issue.

--AaronM_Cloudtek (talk) 05:31, 25 March 2019 (UTC)

I think perhaps this could be included in a general section about signing binaries. Whether you use shim, preloader, or your own keys, you still have to sign the binaries. The only real difference is where the certificate is stored (db, or MOKList).
Soroshi (talk) 20:32, 24 December 2019 (UTC)

SBUpdate Behaviour Update

 "sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."

This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)

—This unsigned comment is by Superherointj (talk) 23:08, 2 July 2019 (UTC). Please sign your posts with ~~~~!

Feel free to remove that note. -- nl6720 (talk) 06:14, 3 July 2019 (UTC)

Booting with own keys but without Microsoft's keys

I was unable to boot my computer (black screen before the POST) after removing Microsoft's keys from firmware and enabling Secure boot. This was because of my graphic card, as explained in Rod Smith's article:

Some plug-in cards have firmware that's signed by Microsoft's keys. Such a card will not work (at least, not from the firmware) if you enable Secure Boot without the matching public key. (The card should still work once you've booted an OS. The biggest concern is for cards that must work in a pre-boot environment, such as a video card or for PXE-booting a network card.) You can add Microsoft's keys back to the environment to make such cards work, but this eliminates the advantages of not having those keys, if that's a significant factor for you.
Rod Smith's Controlling Secure Boot

I was able to fix it by extracting the UEFI driver (GOP) from the video BIOS of my card, signing it with my own key and re-flashing the VBIOS. It might not be possible with every cards. Anyway, it should be specified that removing Microsoft's keys can render the boot impossible, independently of the dual booting with Windows.

—This unsigned comment is by Palimpseste (talk) 07:09, 10 December 2019‎. Please sign your posts with ~~~~!

Having gone through this process myself recently, I am considering re-writing this section to be much clearer. I am wondering what general skill level should be targeted with this section. It is certainly not a simple procedure, but it's not that complicated either. My changes would be based on Rod Smith's guide, as well as the [excellent guide on the Gentoo wiki]. I also think that the subsection on signing EFI binaries and kernels should be moved to it's own section, as this is relevant regardless of whether you are using your own keys, shim, or preloader.
Soroshi (talk) 20:24, 24 December 2019 (UTC)