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)


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)

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)

Accuracy of "od" command to determine status

I just set up secure boot with my own keys, following all the instructions here. After setting everything up and enrolling my keys using KeyTool, I wanted to check my secureboot status using the mentioned od command. This is what I got:

~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*
  6   0   0   0   1   7   0   0   0   3

However, the wiki states: If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: 6 0 0 0 1

So I assumed something went wrong. The wiki text sounds a lot like secure boot is enabled if and only if I get exactly 5 digits with the last one being a 1. Now the keen observer might have noticed that my first 5 digits match those from the wiki exactly. But there is 5 additional ones. The other command mentioned in the wiki tells me secureboot is enabled:

~ bootctl status
systemd-boot not installed in ESP.
No default/fallback boot loader installed in ESP.
    Firmware: UEFI 2.70 (Dell 1.00)
 Secure Boot: enabled
  Setup Mode: user

Keytool also tells me that secure boot is in "User Mode". And my Firmware settings tell me secure boot is enabled. (Tested several times now) I also tried booting an unsigned binary which the firmware refused. I am not too sure what the od command does, maybe someone with more insight can clarify. LoNaAleim (talk) 19:48, 24 August 2020 (UTC)

Booting Windows with custom bootloader signature

Windows 10 can boot with custom bootloader signature. I signed bootmgfw.efi and Windows still works normally.

$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi 
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010
signature 2
image signature issuers:
 - /CN=[redacted] - Secure Boot DB
image signature certificates:
 - subject: /CN=[redacted] - Secure Boot DB
   issuer:  /CN=[redacted] - Secure Boot DB

I don't currently have any other keys enrolled, apart from mine.

$ efi-readvar 
Variable PK, length 863
PK: List 0, type X509
    Signature 0, size 835, owner [redacted-2]
            CN=[redacted] - Secure Boot PK
            CN=[redacted] - Secure Boot PK
Variable KEK, length 865
KEK: List 0, type X509
   Signature 0, size 837, owner [redacted-2]
           CN=[redacted] - Secure Boot KEK
           CN=[redacted] - Secure Boot KEK
Variable db, length 863
db: List 0, type X509
    Signature 0, size 835, owner [redacted-2]
            CN=[redacted] - Secure Boot DB
            CN=[redacted] - Secure Boot DB
Variable dbx has no entries
Variable MokList has no entries

(fields replaced with [redacted] have the same value; same goes for [redacted-2])

I am not sure if it works for others. For reference, my machine is a ThinkPad E14, machine type 20RA. Maybe someone can confirm this on their machines and add something to the wiki?

P/s : maybe a method to automatically sign updates from Microsoft?

Cipher (talk) 04:59, 5 November 2020 (UTC)

Add a warning to warn users about dodgy firmware

Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented in this issue. The summary of this is: Secure Boot means that all Option-ROMs must be signed and I used custom keys (with sbctl). The firmware decided it has to validate the Option-ROMs with my custom keys now, which fails. Since my setup did not have an integrated GPU/APU the GPU did not get initialized (since the Option-ROM could not be validated, for some reason an internal GPU/APU does not need one) and the motherboard failed to POST and got caught in a loop. I had to send my motherboard to MSI so they could "repair" the firmware.

I am not a firmware expert, but this might affect other motherboards too. Since some firmwares can behave strange, I am in favor of maybe adding a warning mentioning potential consequences, especially when not using the Microsoft keys.

A very similar issue is apparently present in some Dell motherboards.

Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing /sys in a chroot for example, is vaguely related. I heard this is common in Lenovo devices, so not only my specific motherboard (vendor) has related firmware quirks and this is why this maybe warrants a Template:Warning.

-- NetSysFire (talk) 02:51, 1 April 2021 (UTC)

I've added a warning note at the beginning of the section about using your own custom keys. Some people have complained that their Thinkpad laptops were also bricked in this fashion, so it seems best to warn people to be cautious and do further research before proceeding. Tensa zangetsu (talk) 20:40, 15 May 2021 (UTC)