Talk:Unified Extensible Firmware Interface/Secure Boot

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-signed^AUR 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)

shim

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 https://wiki.archlinux.org/index.php/REFInd#Tools

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)

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)

An alternative to signing the UEFI driver of the video card is enrolling its hash into db, as sbctl developer discusses on the github wiki: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom This can be done using the "at best experimental" -t option of sbctl. He also discusses how to check if there were any third party UEFI drivers signed with the Microsoft key using TPM. I checked ASUS UX325 laptop (Intel 11th Gen CPU with integrated graphics) using this method, and there were no third party drivers. I removed the Microsoft keys, and nothing is bricked.

Crankycrank (talk) 19:20, 22 January 2023 (UTC)

The experimental flag --tmp-eventlog (or -t) worked exceptionally well for me, no Microsoft keys anymore. In my case, I had a single BOOT_SERVICES_DRIVER in the logs, that I suspect is my NVIDIA card (I tried removing the Microsoft keys before and the graphics wouldn't come up). Given the simplicity of the method, I think it could be mentioned in section 5.2 Enrolling Option ROM digests. I know the method is experimental, but using digest-to-efi-sig-list doesn't sound like that much more reliable either, so mentioning the method after the big red warning should be okay. Marmis (talk) 02:52, 31 March 2024 (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]
        Subject:
            CN=[redacted] - Secure Boot PK
        Issuer:
            CN=[redacted] - Secure Boot PK
Variable KEK, length 865
KEK: List 0, type X509
   Signature 0, size 837, owner [redacted-2]
       Subject:
           CN=[redacted] - Secure Boot KEK
       Issuer:
           CN=[redacted] - Secure Boot KEK
Variable db, length 863
db: List 0, type X509
    Signature 0, size 835, owner [redacted-2]
        Subject:
            CN=[redacted] - Secure Boot DB
        Issuer:
            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)

Hi Cipher! I tried booting Windows via bootmgfw, signed with
- both Microsofts key
- and my personal key,
- in SecureBoot mode enabled,
- with my personal SecureBoot keys enrolled in NVRAM;
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows:

Selected boot image did not authenticate. Press ENTER to continue.

It seems like my BIOS can only read the first signature of binary EFI files, not multiple signatures of bootmgfw.efi . My signature on bootmgfw.efi was the second one; Microsofts signature was the first one:

If I delete the Microsoft signature from bootmgfw.efi and only add my own signature, I can get into Windows10 - but only in a Windows10 recovery/repair environment: Windows complains that my Windows10 installation is broken (because the Microsoft Windows signature on bootmgfw.efi is missing).

My BIOS firmware: UEFI 2.31 (INSYDE Corp. 4096.01)

My BIOS firmware in detail:

$ sudo dmidecode -t bios
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.

Handle 0x000E, DMI type 0, 24 bytes
BIOS Information 
	Vendor: Insyde
	Version: F.70
	Release Date: 07/18/2016
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 4 MB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
		Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
		5.25"/360 kB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 15.112
	Firmware Revision: 29.66

So I suppose my UEFI/BIOS implementation is broken. My BIOS can probably only read the first signature of signed binary EFI files.

Here's my code:

$ cd /esp/EFI/Microsoft/Boot 

$ sudo sbsign --key  /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \
             --cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \
             --output bootmgfw.efi.signed bootmgfw.efi 
Image was already signed; adding additional signature

$ mv bootmgfw.efi bootmgfw.efi.backup 
$ mv bootmgfw.efi.signed bootmgfw.efi 

$ sbverify --list bootmgfw.efi.backup 
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

$ sbverify --list 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> DB
image signature certificates:
- subject: /CN=<redacted> DB
  issuer:  /CN=<redacted> DB

$ cd /esp/EFI/BOOT/
$ sudo sbsign --key  /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \
             --cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \
             --output bootx64.efi.signed bootx64.efi

$ mv bootx64.efi bootx64.efi.backup 
$ mv bootx64.efi.signed bootx64.efi 

$ sbverify --list bootx64.efi.backup 
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

$ sbverify --list bootx64.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> DB
image signature certificates:
- subject: /CN=<redacted> DB
  issuer:  /CN=<redacted> DB

I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft:

$ efi-readvar 
Variable PK, length 843
PK: List 0, type X509
   Signature 0, size 815, owner <redacted>
       Subject:
           CN=<redacted> PK
       Issuer:
           CN=<redacted> PK
Variable KEK, length 845
KEK: List 0, type X509
   Signature 0, size 817, owner <redacted>
       Subject:
           CN=<redacted> KEK
       Issuer:
           CN=<redacted> KEK
Variable db, length 843
db: List 0, type X509
   Signature 0, size 815, owner <redacted>
       Subject:
           CN=<redacted> DB
       Issuer:
           CN=<redacted> DB
Variable dbx, length 76
dbx: List 0, type SHA256
   Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000
       Hash:0000000000000000000000000000000000000000000000000000000000000000

I have booted into SecureBootMode:

$ bootctl status 
System:
    Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)
 Secure Boot: enabled
  Setup Mode: user
TPM2 Support: no
Boot into FW: supported

DasMenschy (talk) 16:49, 21 September 2021 (UTC)

Yeah, your firmware doesn't seem to recognize additional signatures from a binary. Did you try to append Microsoft's key to the signature database (the db variable)?

(By the way, please indent your replies next time. It would be easier for people to separate out messages.)

Cipher (talk) 15:39, 21 December 2021 (UTC)

Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 (MicWinProPCA2011_2011-10-19.crt ) into the UEFI Secure Boot db variable; I am able to boot Windows. But I wanted to achieve it without enrolling any Microsoft key into the db variable. I would like to avoid future security holes like BOOTHOLE, which AFAIK were introduced because Microsoft signs almost anything (probably including government surveillance tools). As far as I know, Microsoft doesn't really check the programs it signs for security vulnerabilities.

Currently, I am working around it by only enrolling the hashes of bootmgfw.efi into the db variable - then Windows can also be booted, but without the Microsoft UEFI keys. But of course, that's a lot of work: every time the bootmgfw.efi changes because of a Windows 10 update, I also have to update the db variable. And at some point in the future, the db variable stored on small NVRAM will be full - no more hashes can be added. So another solution would be nice. DasMenschy (talk) 21:32, 21 December 2021 (UTC)

Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.

Regarding the issue with automating hash enrollment, I have not found a solution either. So far, the Windows binary has to be signed/enrolled before booting, and I do not know whether that is possible inside Windows itself during updates. If that is not the case, you will have to reboot back to Linux to do it, be it automatic or manual (I semi-automated that with the pacman hook as described in the wiki page).

About the db variable, I believe you can wipe it and reinstall your own keys with fresh Windows hashes to deal with space issues (not sure if that could be done inside Linux though). Automate it (maybe a hook at kernel signing? After all, kernel updates are released more frequently than Windows updates, right?) and the issue should be resolved.

Also, I am not sure if Windows requires Microsoft signature to be the first - but if it doesn't, maybe we can do some shenanigans to switch your signature to the first entry, effectively satisyfing both Secure Boot and Windows?

Cipher (talk) 02:17, 22 December 2021 (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)

The current warning isn't much help in finding out if one's device is going to be affected. Is this reliable enough to be added to the wiki as a possible check ? --Cvlc (talk) 21:44, 30 December 2021 (UTC)

Simplify the page by removing old instructions

There is a lot of text and alternative solutions to the same problems on this page. For instance, do we really need openssl, when sbkeys gets the job done just fine? Because there is no clear structure of alternative paths, the procedure is hard to follow even though I have done this many times before. I suggest either removing the older options, or moving them to separate pages, leaving only the most modern / automated workflow on the main article. A related concern is the manual creation of the /etc/secureboot/keys directory tree. Is there no tool that automatically puts the keys in the right folders, while also creating all the keys, optionally including the Microsoft ones? Foonoxous (talk) 15:16, 27 November 2021 (UTC)

There isn't any easy tools for doing any of this which is why I started writing sbctl]. However I'm not super comfortable adding it to Arch Wiki.

Foxboron (talk) 19:44, 2 January 2022 (UTC)

I've used sbctl for some time now and I think it is stable enough for addition to the wiki. Perhaps it could be prefaced with a warning for users to understand the full secure boot setup process before using it.

Kiasoc5 (talk) 19:16, 16 May 2022 (UTC)

about restoring OEM keys

This is a little off-topic, but: What about a mention that some firmware utility (BIOS) allow you to restore OEM keys, if cleared and deleted to enable back Secure Boot in User Mode, to quit Setup Mode

—This unsigned comment is by Solstice (talk) 14:12, 5 August 2022‎. Please sign your posts with ~~~~!

Yes, that's a good point, it should be mentioned in this article that many UEFI implementations allow you to restore default / OEM keys! Where would you put that information?

• Option 1: At the end of section "3.1 Using your own keys", just after "3.1.7 Dual booting with other operating systems", a section: "3.1.8 Restoring the OEM Secure Boot variables"?
• Option 2: Or included in the section "3.1.2 Backing up current variables"?

DasMenschy (talk) 21:27, 5 August 2022 (UTC)

Section "Shim with key and GRUB"

Concerning the section Unified Extensible Firmware Interface/Secure Boot#Shim with key and GRUB:

Do you think it is necessary to include an explanation what all the "basic" GRUB modules are doing, in the first code block? I couldn't find any good documentation about all these modules, I only found this thread on linux.org, which doesn't have all modules however and is already outdated. The official GNU GRUB manual has no documentation at all about the modules.

Do you think dividing the list of GRUB modules into these three parts, as done in the official Ubuntu build script, is meaningful, or is it arbitrarily / nonsensical?

Thank you in advance for help!

DasMenschy (talk) 12:42, 28 August 2022 (UTC)

This section is definitely not up to the quality standards of the wiki. The linuxefi module referenced isn't even in upstream GRUB, it's a fedora-specific patch (also adopted by ubuntu). Also the GRUB_MODULES variable expansion should be between parentheses. Unless one requires the flexibility of GRUB, I suppose the best way to use Secure Boot with shim and machine owner key (on oem laptops with inflexible bios options for Secure Boot) is going the Unified Kernel Image way and using pacman hooks for that Blaatschaap (talk) 12:30, 11 October 2022 (UTC) EDIT: turns out this does not work either, with newer shim (from 15.3rc4+, pretty old by now) you need to build GRUB with fedora patches due to shim hardening Blaatschaap (talk) 12:55, 11 October 2022 (UTC)

Hi User:Blaatschaap, the problem with the approach you mentioned is however that shim (with the Microsoft signature) can only launch a bootloader file called "grubx64.efi". So if you want to go the "shim + Unified kernel Image" way, you would have to call the Unified kernel image file "grubx64.efi". That's a quite dirty hack and quite irritating. You must trick shim into treating the Unified kernel image file as if it were the grub file.

The file path / file name "grubx64.efi" is hard-coded (!) into the binary shim file. You could compile shim yourself, so that shim can also launch other binaries, that are not called "grubx64.efi", but these shim files then won't have any Microsoft signature; so they won't work on OEM laptops. Somehow Microsoft forced the shim developers to hardcode "grubx64.efi" into the binary shim file. I hate Microsoft because of that. Microsoft forces us to do dirty hacks.

DasMenschy (talk) 13:06, 11 October 2022 (UTC)

Hardcoding "grubx64.efi" into the shim binary does not offer any security benefit, but makes life harder for everyone. DasMenschy (talk) 13:13, 11 October 2022 (UTC)

Nevertheless, if you call the Unified kernel image file "grubx64.efi" and if you include a sbat.csv file in it, I think you should be able to launch it with shim. That's the only thing necessary for the "shim hardening". This is not such a big problem. DasMenschy (talk) 13:13, 11 October 2022 (UTC)

I do like what you did. I just made a bunch of style fixes; the most significant change was that I removed the direct excerpt of the Ubuntu build script because I don't want to paste a lot of code that we can just link to. Within the group of "basic" modules, an area of future expansion could be adding descriptions for (a subset of) them. -- CodingKoopa (talk) 18:15, 16 October 2022 (UTC)

I think the best way is to replace grub with

• refind or
• systemdboot

and then rename the

• "refindx64.efi" or
• "systemdbootx64.efi"

... file to "grubx64.efi", so that shim can launch them. The

• refind-install-script or
• systemdboot-install-script

... should then also drop a file in the grubx64.efi directory, explaining that the grubx64.efi file is not grub, like so:

• "grubx64-efi-is-not-grub-but-refind.txt" or
• "grubx64-efi-is-not-grub-but-systemdboot.txt"

• refind or
• systemdboot

... can then launch the Unified kernel image files. I think this approach is a bit more meaningful. But an explanation for this should not be put into the "grub" section, that's another topic.

DasMenschy (talk) 13:28, 11 October 2022 (UTC)

About signing files from the esp

Some part of this page suggest that files should be signed in-place on the esp, for instance:

sbctl sign -s /boot/vmlinuz-linux
sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

While this will indeed work, I think it is going against the idea of secure boot (preventing execution of untrusted code on boot).

The file paths suggest an esp mounted on /boot. The esp is not ciphered and anybody can write on it and tamper files stored on it. Thus, when running the commands above, you can end-up signing a malicious file (and then have it executed on boot as trusted code).

I believe it would be a better example to sign a file from a trusted source.

Also, now that UKI are integrated in mkinitcpio, it could probably be used as a basic example of a file to sign.

To give a more secure example, I suggest replacing the above examples with something like the following:

‎

Assuming:‎

1. esp is mounted to /efi
2. /boot is part of a ciphered partition
3. there is a unified kernel image in /boot/arch-linux.efi

Sign your UKI with:

sbctl sign -s -o /efi/EFI/Linux/arch-linux.efi /boot/arch-linux.efi

WDYT? Ggd (talk) 20:48, 2 October 2023 (UTC)

Enrolling keys with sbctl enables Secure Boot

According to sbctl(8), enrolling keys with sbctl automatically takes the UEFI BIOS out of Setup Mode and enables Secure Boot (assuming the firmware is compatible with sbctl). I haven't tested this yet, but will be doing so in a little over a week from now.

If it does work, I'll update this section of the article and adjust references to manually enabling Secure Boot. Ectospasm (talk) 22:16, 16 December 2023 (UTC)

I'll spare you the trouble, you need to enable it manually in the settings. The manpage isn't very precise on this. Foxboron (talk) 22:31, 16 December 2023 (UTC)

Ahh, OK. Good to know. I'll update my recipe for my next Arch install. Thanks! Should I draft a PR for the sbctl(8) update to eliminate what caused my confusion? I also see a typo in the sentence before it. Ectospasm (talk) 03:53, 17 December 2023 (UTC)

PR submitted, @Foxboron Ectospasm (talk) 23:01, 17 December 2023 (UTC)

Actually, my Lenovo ThinkPad X1 Carbon, 11th gen does NOT offer a way to enable Secure Boot in the UEFI BIOS settings. I can disable Secure Boot, enter Setup Mode, but it looks like enabling Secure Boot has to come from the OS. Which makes sense, if the OS isn't ready for Secure Boot you have no hope of booting with it enabled.

I've tried it a couple of times--due to a firwmare upgrade unexpectedly (to me, anyway) changing the hash of the firmware, and my TPM PCR had the wrong hash, I ended up having to repeat the installation process again after the initial successful attempt--both times I enabled Secure Boot with sbctl enroll-keys --microsoft. Ectospasm (talk) 14:11, 6 January 2024 (UTC)

How to restore the backed up EFI variables

The section talks about backing up the current EFI variables in the beginning, but it doesn't talk about how to restore the EFI variables. My system is a little bit messed up as enabling secure boot makes Windows bitlocker activate saying that "Secure Boot Policy has unexpectedly changed." Enabling secure boot also makes GRUB say "prohibited by secure boot policy." I have to turn off secure boot to access my Linux system. Hueychen (talk) 22:02, 4 January 2024 (UTC)

Merge/Link sections about ISO repacking

I think section 5.2 Replacing the boot loader with PreLoader could be merged into 5.1 ISO repacking.

Further, they both could be either put into section 2 Booting an installation medium, or (if it's considered too niche) they should be at least linked from there for discoverability.

Mearon (talk) 11:06, 6 March 2024 (UTC)

As the person who wrote section 5.2: Yeah, it absolutely should be merged into 5.1. I think I just forgot to add an extra = when writing the section title.

There is a link to section 5.2 in 2.2 Repacking the installation image. I chose that section to link to because it made more sense to me, in a "I cannot disable Secure Boot or change the installed Microsoft keys but I want to boot Arch" way. I think it is a bit niche, but I do not think these instructions would be completely out of place in section 2. Maybe after section 2.3 Editing the installation medium? Aurantius (talk) 14:36, 6 March 2024 (UTC)

Thanks for your feedback! I moved it into ISO Repacking and adjusted the link you mentioned in 2.2 Repacking the installation image. Not sure how I missed that :S I think it looks good now and agree that it's a bit more niche, so I'll leave it in Tips and tricks for now. Mearon (talk) 14:59, 6 March 2024 (UTC)