Secure Boot
For an overview about Secure Boot in Linux see Rodsbooks' Secure Boot article. This article focuses on how to set up Secure Boot in Arch Linux.
Contents
Booting archiso
Booting the archiso with Secure Boot enabled is possible since the EFI applications PreLoader.efi
and HashTool.efi
have been added to it. A message will show up that says Failed to Start loader... I will now execute HashTool.
To use HashTool for enrolling the hash of loader.efi
and vmlinuz.efi
, follow these steps.
- Select OK
- In the HashTool main menu, select Enroll Hash, choose
\loader.efi
and confirm with Yes. Again, select Enroll Hash andarchiso
to enter the archiso directory, then selectvmlinuz.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
The archiso boots, and you are presented with a shell prompt, automatically logged in as root. To check if the archiso was booted with Secure Boot, use this command:
$ od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
The characters denoted by XXXX
differ from machine to machine. To help with this, you can use tab completion or list the EFI variables.
If a Secure Boot is enabled, this command returns 1
as the final integer in a list of five, for example:
6 0 0 0 1
For a verbose status, another way is to execute:
# bootctl status
Using a signed boot loader
Using a signed boot loader means using a boot loader signed with Microsoft's key. There are two known signed boot loaders PreLoader and shim, their purpose is to chainload other EFI binaries (usually boot loaders). Since Microsoft would never sign a boot loader that automatically launches any unsigned binary, PreLoader and shim use a whitelist called Machine Owner Key list. If the SHA256 hash of the binary (Preloader and shim) or key the binary is signed with (shim) is in the MokList they execute it, if not they launch a key management utility which allows enrolling the hash or key.
PreLoader
When run, PreLoader tries to launch loader.efi
, if the hash of loader.efi
is not in MokList, PreLoader will launch HashTool.efi
. In HashTool you must enroll the hash of the EFI binaries you want to launch, that means your boot loader (loader.efi
) and kernel.
refind-install
script can copy the rEFInd and PreLoader EFI binaries to the ESP. See rEFInd#Using PreLoader for instructions.Set up PreLoader
PreLoader.efi
and HashTool.efi
in efitools package are not signed, so their usefulness is limited. You can get a signed PreLoader.efi
and HashTool.efi
from preloader-signedAUR or download them manually.Install preloader-signedAUR and copy PreLoader.efi
and HashTool.efi
to the boot loader directory; for systemd-boot use:
# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi esp/EFI/systemd
Now copy over the boot loader binary and rename it to loader.efi
; for systemd-boot use:
# cp esp/EFI/systemd/systemd-bootx64.efi esp/EFI/systemd/loader.efi
Finally, create a new NVRAM entry to boot PreLoader.efi
:
# efibootmgr --verbose --disk /dev/sdX --part Y --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi
Replace X
with the drive letter and replace Y
with the partition number of the EFI system partition.
This entry should be added to the list as the first to boot; check with the efibootmgr
command and adjust the boot-order if necessary.
Fallback
If there are problems booting the custom NVRAM entry, copy HashTool.efi
and loader.efi
to the default loader location booted automatically by UEFI systems:
# cp /usr/share/preloader-signed/HashTool.efi esp/EFI/Boot # cp esp/EFI/systemd/systemd-bootx64.efi esp/EFI/Boot/loader.efi
Copy over PreLoader.efi
and rename it:
# cp /usr/share/preloader-signed/PreLoader.efi esp/EFI/Boot/bootx64.efi
For particularly intransigent UEFI implementations, copy PreLoader.efi
to the default loader location used by Windows systems:
# mkdir -p esp/EFI/Microsoft/Boot # cp /usr/share/preloader-signed/PreLoader.efi esp/EFI/Microsoft/Boot/bootmgfw.efi
bootmgfw.efi
first as replacing it may cause problems with Windows updates.As before, copy HashTool.efi
and loader.efi
to esp/EFI/Microsoft/Boot/
.
When the system starts with Secure Boot enabled, follow the steps above to enroll loader.efi
and /vmlinuz-linux
(or whichever kernel image is being used).
Remove PreLoader
Uninstall preloader-signedAUR and simply remove the copied files and revert configuration; for systemd-boot use:
# rm esp/EFI/systemd/{PreLoader,HashTool}.efi # rm esp/EFI/systemd/loader.efi # efibootmgr --verbose --bootnum N --delete-bootnum # bootctl update
Where N
is the NVRAM boot entry created for booting PreLoader.efi
.
Check with the efibootmgr command and adjust the boot-order if necessary.
shim
When run, shim tries to launch grubx64.efi
, if MokList does not contain the hash of grubx64.efi
or the key it is signed with, shim will launch MokManager (mmx64.efi
). In MokManager you must enroll the hash of the EFI binaries you want to launch (your boot loader (grubx64.efi
) and kernel) or enroll the key they are signed with.
Set up shim
refind-install
script can sign rEFInd EFI binaries and copy them along with shim and the MOK certificates to the ESP. See rEFInd#Using shim for instructions.Install shim-signedAUR.
Rename your current boot loader to grubx64.efi
# mv esp/EFI/BOOT/BOOTX64.efi esp/EFI/BOOT/grubx64.efi
Copy shim and MokManager to your boot loader directory on ESP; use previous filename of your boot loader as as the filename for shimx64.efi
:
# cp /usr/share/shim-signed/shimx64.efi esp/EFI/BOOT/BOOTX64.efi # cp /usr/share/shim-signed/mmx64.efi esp/EFI/BOOT/
shim can authenticate binaries by Machine Owner Key or hash stored in MokList.
- Machine Owner Key (MOK)
- A key that a user generates and uses to sign EFI binaries.
- hash
- A SHA256 hash of an EFI binary.
Using hash is simpler, but each time you update your boot loader or kernel you will need to add their hashes in MokManager. With MOK you only need to add the key once, but you will have to sign the boot loader and kernel each time it updates.
shim with hash
If shim does not find the SHA256 hash of grubx64.efi
in MokList it will launch MokManager (mmx64.efi
).
In MokManager select Enroll hash from disk, find grubx64.efi
and add it to MokList. Repeat the steps and add your kernel vmlinuz-linux
. When done select Continue boot and your boot loader will launch and it will be capable launching the kernel.
shim with key
Install sbsigntools.
You will need:
- .key
- PEM format private key for EFI binary signing.
- .crt
- PEM format certificate for sbsign.
- .cer
- DER format certificate for MokManager.
Create a Machine Owner Key:
$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Machine Owner Key/" -out MOK.crt $ openssl x509 -outform DER -in MOK.crt -out MOK.cer
Sign your boot loader (named grubx64.efi
) and kernel:
# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux # sbsign --key MOK.key --cert MOK.crt --output esp/EFI/BOOT/grubx64.efi esp/EFI/BOOT/grubx64.efi
You will need to do this each time they are updated. You can automate the kernel signing with a pacman hook, e.g.:
/etc/pacman.d/hooks/999-sign_kernel_for_secureboot.hook
[Trigger] Operation = Install Operation = Upgrade Type = Package Target = linux [Action] Description = Signing kernel with Machine Owner Key for Secure Boot When = PostTransaction Exec = /usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null | /usr/bin/grep -q "signature certificates"; then /usr/bin/sbsign --key MOK.key --cert MOK.crt --output {} {}; fi' \; Depends = sbsigntools findutils grep
Copy MOK.cer
to a FAT formatted file system (you can use EFI system partition).
Reboot and enable Secure Boot. If shim does not find the certificate grubx64.efi
is signed with in MokList it will launch MokManager (mmx64.efi
).
In MokManager select Enroll key from disk, find MOK.cer
and add it to MokList. When done select Continue boot and your boot loader will launch and it will be capable launching any binary signed with your Machine Owner Key.
Remove shim
Uninstall shim-signedAUR, remove the copied shim and MokManager files and rename back your boot loader.
Using your own keys
- It is advised to read Rod Smith's Controlling Secure Boot.
- You can use
cryptboot-efikeys
script from cryptbootAUR package for simplified creating keys, enrolling keys, signing bootloader and verifying signatures.- Note that cryptbootAUR requires the encrypted
/boot
partition to be specified in/etc/crypttab
before it runs, and if you are using it in combination with sbupdate-gitAUR, sbupdate expects the/boot/efikeys/db.*
files created by cryptboot to be capitalized likeDB.*
unless otherwise configured in/etc/default/sbupdate
. Users who do not use systemd to handle encryption may not have anything in their/etc/crypttab
file and would need to create an entry.
- Note that cryptbootAUR requires the encrypted
Secure Boot implementations use these keys:
- Platform Key (PK)
- Top-level key.
- Key Exchange Key (KEK)
- Keys used to sign Signatures Database and Forbidden Signatures Database updates.
- Signature Database (db)
- Contains keys and/or hashes of allowed EFI binaries.
- Forbidden Signatures Database (dbx)
- Contains keys and/or hashes of blacklisted EFI binaries.
See The Meaning of all the UEFI Keys for a more detailed explanation.
Custom keys
To use Secure Boot you need at least PK, KEK and db keys. While you can add multiple KEK, db and dbx certificates, only one Platform Key is allowed.
Once Secure Boot is in "User Mode" keys can only be updated by signing the update (using sign-efi-sig-list) with a higher level key. Platform key can be signed by itself.
Creating keys
To generate keys, install efitools.
You will need private keys and certificates in multiple formats:
- .key
- PEM format private keys for EFI binary and EFI signature list signing.
- .crt
- PEM format certificates for sbsign.
- .cer
- DER format certificates for firmware.
- .esl
- Certificates in EFI Signature List for KeyTool and/or firmware.
- .auth
- Certificates in EFI Signature List with authentication header (i.e. a signed certificate update file) for KeyTool and/or firmware.
Create a GUID for owner identification:
$ uuidgen --random > GUID.txt
Platform key:
$ openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt $ openssl x509 -outform DER -in PK.crt -out PK.cer $ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth
Sign an empty file to allow removing Platform Key when in "User Mode":
$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null rm_PK.auth
Key Exchange Key:
$ openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt $ openssl x509 -outform DER -in KEK.crt -out KEK.cer $ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
Signature Database key:
$ openssl req -newkey rsa:2048 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=my Signature Database key/" -out db.crt $ openssl x509 -outform DER -in db.crt -out db.cer $ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth
Updating keys
Once Secure Boot is in "User Mode" any changes to KEK, db and dbx need to be signed with a higher level key.
For example, if you wanted to replace your db key with a new one:
- Create the new key,
- Convert it to EFI Signature List,
- Sign the EFI Signature List,
- Enroll the signed certificate update file.
$ cert-to-efi-sig-list -g "$(< GUID.txt)" new_db.crt new_db.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db new_db.esl new_db.auth
If instead of replacing your db key, you want to add another one to the Signature Database, you need to use the option -a
(see sign-efi-sig-list(1)):
$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db new_db.esl new_db.auth
When new_db.auth
is created, enroll it.
Signing bootloader and kernel
refind-install
script can sign rEFInd EFI binaries and copy them together with the db certificates to the ESP. See rEFInd#Using your own keys for instructions.When Secure Boot is active (i.e. in "User Mode") you will only be able to launch signed binaries, so you need to sign your kernel and boot loader.
Install sbsigntools.
--output
the resulting file will be filename.signed
. See sbsign(1) for more information.# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux # sbsign --key db.key --cert db.crt --output esp/EFI/BOOT/BOOTX64.EFI esp/EFI/BOOT/BOOTX64.EFI
- To check if a binary is signed and list its signatures use
sbverify --list /path/to/binary
. - You can use sbupdate-gitAUR to automatically sign your kernels on update. This will also take care of embedding the otherwise unprotected initramfs and kernel command line into the signed UEFI image.
- When using sbupdate-gitAUR,
CMDLINE_DEFAULT
must be set in/etc/default/sbupdate
in order for the .efi image to be bootable. - You may want to consider using Direct UEFI boot with efibootmgr after generating the signed .efi file.
- When using sbupdate-gitAUR,
Signing kernel with pacman hook
You can also create your own pacman hook to sign kernel on install and updates.
/etc/pacman.d/hooks/99-secureboot.hook
[Trigger] Operation = Install Operation = Upgrade Type = Package Target = linux [Action] Description = Signing Kernel for SecureBoot When = PostTransaction Exec = /usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null | /usr/bin/grep -q "signature certificates"; then /usr/bin/sbsign --key db.key --cert db.crt --output {} {}; fi' \; Depends = sbsigntools findutils grep
Put firmware in "Setup Mode"
Secure Boot is in Setup Mode when the Platform Key is removed. To put firmware in Setup Mode, enter firmware setup utility and find an option to delete or clear certificates.
Enroll keys in firmware
Copy all *.cer
, *.esl
, *.auth
to a FAT formatted file system (you can use EFI system partition).
Launch firmware setup utility or KeyTool and enroll db, KEK and PK certificates.
If the used tool supports it prefer using .auth and .esl over .cer.
Using firmware setup utility
Firmwares have various different interfaces, see Replacing Keys Using Your Firmware's Setup Utility for example how to enroll keys.
Using KeyTool
KeyTool.efi
is in efitools package, copy it to ESP. To use it after enrolling keys, sign it with sbsign
.
# sbsign --key db.key --cert db.crt --output esp/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi
Launch KeyTool-signed.efi
using firmware setup utility, boot loader or UEFI Shell and enroll keys.
See Replacing Keys Using KeyTool for explanation of KeyTool menu options.
Dual booting with other operating systems
Microsoft Windows
To dual boot with Windows, you would need to add Microsoft's certificates to the Signature Database. Microsoft has two db certificates:
- Microsoft Windows Production PCA 2011 for Windows
- Microsoft Corporation UEFI CA 2011 for third-party binaries like UEFI drivers, option ROMs etc.
Microsoft's certificates are in DER format, convert them to PEM format with openssl:
$ openssl x509 -inform DER -outform PEM -in MicWinProPCA2011_2011-10-19.crt -out MicWinProPCA2011_2011-10-19.crt.pem $ openssl x509 -inform DER -outform PEM -in MicCorUEFCA2011_2011-06-27.crt -out MicCorUEFCA2011_2011-06-27.crt.pem
Create EFI Signature Lists with Microsoft's GUID (77fa9abd-0359-4d32-bd60-28f4e78f784b
) and combine them in one file for simplicity:
$ cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicWinProPCA2011_2011-10-19.crt.pem MS_Win_db.esl $ cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt.pem MS_UEFI_db.esl $ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl
Sign a db update with your KEK. Use sign-efi-sig-list
with option -a
to add not replace a db certificate:
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth
Follow #Enroll keys in firmware to add add_MS_db.auth
to Signature Database.
Disable Secure Boot
The Secure Boot feature can be disabled via the UEFI firmware interface. You may access the firmware configuration by pressing a special key during the boot process. The key to use depends on the firmware. It is usually one of Esc
, F2
, Del
or possibly another Fn
key.
If using a hotkey did not work and you can boot Windows, you can force a reboot into the firmware configuration in the following way (for Windows 10): Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart.
Note that some motherboards (this is the case in a Packard Bell laptop) only allow to disable secure boot if you have set an administrator password (that can be removed afterwards). See also Rod Smith's Disabling Secure Boot.
See also
- Wikipedia:Unified Extensible Firmware Interface#Secure boot
- Dealing with Secure Boot by Rod Smith
- Controlling Secure Boot by Rod Smith
- UEFI secure booting (part 2) by Matthew Garrett
- UEFI Secure Boot by James Bottomley
- efitools README
- Will your computer's "Secure Boot" turn out to be "Restricted Boot"? — Free Software Foundation
- Free Software Foundation recommendations for free operating system distributions considering Secure Boot
- Intel's UEFI Secure Boot Tutorial