https://wiki.archlinux.org/api.php?action=feedcontributions&user=FeedMeWeirdThings&feedformat=atomArchWiki - User contributions [en]2024-03-29T06:13:35ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=566720Unified Extensible Firmware Interface/Secure Boot2019-02-16T21:08:35Z<p>FeedMeWeirdThings: Removed duplicate of "The Secure Boot feature can be disabled via the UEFI firmware interface."</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Secure Boot]]<br />
{{Move|Unified Extensible Firmware Interface/Secure Boot|Secure Boot is a direct UEFI feature.|section=Move to "Unified Extensible Firmware Interface/Secure Boot"}}<br />
{{Expansion|Need to explain the relationship with Win8 which is already documented in [[Dual boot with Windows#UEFI Secure Boot]]. Not sure how to integrate the info without duplication.}}<br />
{{Related articles start}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
For an overview about Secure Boot in Linux see [http://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article. This article focuses on how to set up Secure Boot in Arch Linux. <br />
<br />
== Secure Boot status ==<br />
<br />
=== Check the status ===<br />
==== Before booting the OS ====<br />
<br />
At this point, one has to look at the firmware setup. If the machine was booted and is running, in most cases it will have to be rebooted. <br />
<br />
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 {{ic|Esc}}, {{ic|F2}}, {{ic|Del}} or possibly another {{ic|F''n''}} key. Sometimes the right key is displayed for a short while at the beginning of the boot process. The motherboard manual usually records it. You might want to press the key, and keep pressing it, immediately following powering on the machine, even before the screen actually displays anything.<br />
<br />
After entering the firmware setup, be careful not to change any settings without prior intention. Usually there are navigation instructions, and short help for the settings, at the bottom of each setup screen. The setup itself might be composed of several pages. You will have to navigate to the correct place. The interesting setting might be simply denoted by secure boot, which can be set on or off.<br />
<br />
==== After booting the OS ====<br />
To check if the machine was booted with Secure Boot, use this command:<br />
<br />
$ od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''<br />
<br />
The characters denoted by {{ic|''XXXX''}} differ from machine to machine. To help with this, you can use tab completion or list the EFI variables.<br />
<br />
If Secure Boot is enabled, this command returns {{ic|1}} as the final integer in a list of five, for example:<br />
<br />
6 0 0 0 1<br />
<br />
For a verbose status, another way is to execute:<br />
<br />
$ bootctl status<br />
<br />
=== Change the status ===<br />
{{Expansion|Layout quick steps how an Arch install can gain Secure Boot with either [[#Using a signed boot loader]] or [[#Using your own keys]]. In the steps it is best mentioned that the structure of those two sections relies on having booted into Arch, i.e. [[#Disable Secure Boot]] first.}}<br />
<br />
== Using a signed boot loader ==<br />
<br />
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 loader]]s). 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.<br />
<br />
=== PreLoader ===<br />
<br />
When run, PreLoader tries to launch {{ic|loader.efi}}, if the hash of {{ic|loader.efi}} is not in MokList, PreLoader will launch {{ic|HashTool.efi}}. In HashTool you must enroll the hash of the EFI binaries you want to launch, that means your [[boot loader]] ({{ic|loader.efi}}) and kernel.<br />
<br />
{{Note|Each time you update any of the binaries (e.g. boot loader or kernel) you will need to enroll their new hash.}}<br />
<br />
{{Tip|The [[rEFInd]] boot manager's {{ic|refind-install}} script can copy the rEFInd and PreLoader EFI binaries to the ESP. See [[rEFInd#Using PreLoader]] for instructions.}}<br />
<br />
==== Set up PreLoader ====<br />
<br />
{{Note|{{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} package are not signed, so their usefulness is limited. You can get a signed {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually].}}<br />
<br />
[[Install]] {{AUR|preloader-signed}} and copy {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} to the [[boot loader]] directory; for [[systemd-boot]] use:<br />
<br />
# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd<br />
<br />
Now copy over the boot loader binary and rename it to {{ic|loader.efi}}; for [[systemd-boot]] use:<br />
<br />
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi<br />
<br />
Finally, create a new NVRAM entry to boot {{ic|PreLoader.efi}}:<br />
<br />
# efibootmgr --verbose --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi<br />
<br />
Replace {{ic|''X''}} with the drive letter and replace {{ic|''Y''}} with the partition number of the [[EFI system partition]].<br />
<br />
This entry should be added to the list as the first to boot; check with the {{ic|efibootmgr}} command and adjust the boot-order if necessary.<br />
<br />
===== Fallback =====<br />
<br />
If there are problems booting the custom NVRAM entry, copy {{ic|HashTool.efi}} and {{ic|loader.efi}} to the default loader location booted automatically by UEFI systems:<br />
<br />
# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/Boot<br />
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/Boot/loader.efi<br />
<br />
Copy over {{ic|PreLoader.efi}} and rename it:<br />
<br />
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Boot/bootx64.efi<br />
<br />
For particularly intransigent UEFI implementations, copy {{ic|PreLoader.efi}} to the default loader location used by Windows systems:<br />
<br />
# mkdir -p ''esp''/EFI/Microsoft/Boot<br />
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi<br />
<br />
{{Note|If dual-booting with Windows, backup the original {{ic|bootmgfw.efi}} first as replacing it may cause problems with Windows updates.}}<br />
<br />
As before, copy {{ic|HashTool.efi}} and {{ic|loader.efi}} to {{ic|''esp''/EFI/Microsoft/Boot/}}.<br />
<br />
When the system starts with Secure Boot enabled, follow the steps above to enroll {{ic|loader.efi}} and {{ic|/vmlinuz-linux}} (or whichever kernel image is being used).<br />
<br />
==== How to use while booting? ====<br />
<br />
A message will show up that says {{ic|Failed to Start loader... I will now execute HashTool.}} To use HashTool for enrolling the hash of {{ic|loader.efi}} and {{ic|vmlinuz.efi}}, follow these steps. These steps assume titles for a remastered archiso installation media. The exact titles you will get depends on your boot loader setup.<br />
<br />
* Select ''OK''<br />
* In the HashTool main menu, select ''Enroll Hash'', choose {{ic|\loader.efi}} and confirm with ''Yes''. Again, select ''Enroll Hash'' and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz.efi}} and confirm with ''Yes''. Then choose ''Exit'' to return to the boot device selection menu.<br />
* In the boot device selection menu choose ''Arch Linux archiso x86_64 UEFI CD''<br />
<br />
==== Remove PreLoader ====<br />
<br />
{{Note|Since you are going to remove stuff, is a good idea to backup it.}}<br />
<br />
[[Uninstall]] {{AUR|preloader-signed}} and simply remove the copied files and revert configuration; for [[systemd-boot]] use:<br />
<br />
# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi<br />
# rm ''esp''/EFI/systemd/loader.efi<br />
# efibootmgr --verbose --bootnum ''N'' --delete-bootnum<br />
# bootctl update<br />
<br />
Where {{ic|''N''}} is the NVRAM boot entry created for booting {{ic|PreLoader.efi}}.<br />
Check with the ''efibootmgr'' command and adjust the boot-order if necessary.<br />
<br />
{{Note|The above commands cover the easiest case; if you have created, copied, renamed or edited further files probably you have to handle with them, too. If PreLoader was your operational boot entry, you obviously also need to [[#Disable Secure Boot]].}}<br />
<br />
=== shim ===<br />
<br />
{{Expansion|Testing needed.|section=shim}}<br />
<br />
When run, shim tries to launch {{ic|grubx64.efi}}. If MokList does not contain the hash of {{ic|grubx64.efi}} or the key it is signed with, shim will launch MokManager ({{ic|mmx64.efi}}). In MokManager you must enroll the hash of the EFI binaries you want to launch (your [[boot loader]] ({{ic|grubx64.efi}}) and kernel) or enroll the key they are signed with.<br />
<br />
{{Note|If you use [[#shim with hash]], each time you update any of the binaries (e.g. boot loader or kernel) you will need to enroll their new hash.}}<br />
<br />
==== Set up shim ====<br />
<br />
{{Tip|The [[rEFInd]] boot manager's {{ic|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.}}<br />
<br />
[[Install]] {{AUR|shim-signed}}.<br />
<br />
Rename your current [[boot loader]] to {{ic|grubx64.efi}}<br />
<br />
# mv ''esp''/EFI/BOOT/BOOTX64.efi ''esp''/EFI/BOOT/grubx64.efi<br />
<br />
Copy ''shim'' and ''MokManager'' to your boot loader directory on ESP; use previous filename of your boot loader as as the filename for {{ic|shimx64.efi}}:<br />
<br />
# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTX64.efi<br />
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/<br />
<br />
''shim'' can authenticate binaries by Machine Owner Key or hash stored in MokList.<br />
<br />
; Machine Owner Key (MOK): A key that a user generates and uses to sign EFI binaries.<br />
; hash: A SHA256 hash of an EFI binary.<br />
<br />
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.<br />
<br />
===== shim with hash =====<br />
<br />
If ''shim'' does not find the SHA256 hash of {{ic|grubx64.efi}} in MokList it will launch MokManager ({{ic|mmx64.efi}}).<br />
<br />
In ''MokManager'' select ''Enroll hash from disk'', find {{ic|grubx64.efi}} and add it to MokList. Repeat the steps and add your kernel {{ic|vmlinuz-linux}}. When done select ''Continue boot'' and your boot loader will launch and it will be capable launching the kernel.<br />
<br />
===== shim with key =====<br />
<br />
Install {{Pkg|sbsigntools}}.<br />
<br />
You will need:<br />
<br />
; ''.key'': PEM format '''private''' key for EFI binary signing.<br />
; ''.crt'': PEM format certificate for ''sbsign''.<br />
; ''.cer'': DER format certificate for ''MokManager''.<br />
<br />
Create a Machine Owner Key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt<br />
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer<br />
<br />
Sign your boot loader (named {{ic|grubx64.efi}}) and kernel:<br />
<br />
# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi<br />
<br />
You will need to do this each time they are updated. You can automate the kernel signing with a [[pacman hook]], e.g.:<br />
<br />
{{hc|/etc/pacman.d/hooks/999-sign_kernel_for_secureboot.hook|2=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Type = Package<br />
Target = linux<br />
<br />
[Action]<br />
Description = Signing kernel with Machine Owner Key for Secure Boot<br />
When = PostTransaction<br />
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' ;<br />
Depends = sbsigntools<br />
Depends = findutils<br />
Depends = grep<br />
}}<br />
<br />
Copy {{ic|MOK.cer}} to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
Reboot and enable Secure Boot. If ''shim'' does not find the certificate {{ic|grubx64.efi}} is signed with in MokList it will launch MokManager ({{ic|mmx64.efi}}).<br />
<br />
In ''MokManager'' select ''Enroll key from disk'', find {{ic|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.<br />
<br />
==== Remove shim ====<br />
<br />
[[Uninstall]] {{AUR|shim-signed}}, remove the copied ''shim'' and ''MokManager'' files and rename back your boot loader.<br />
<br />
== Using your own keys ==<br />
<br />
{{Expansion|instructions needed, testing too, a subsection on backing up existing keys prior to replacing them should be added}}<br />
<br />
{{Tip|<br />
* It is advised to read [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot].<br />
* You can use {{ic|cryptboot-efikeys}} script from {{AUR|cryptboot}} package for simplified creating keys, enrolling keys, signing bootloader and verifying signatures.<br />
** Note that {{AUR|cryptboot}} requires the encrypted {{ic|/boot}} partition to be specified in {{ic|/etc/crypttab}} before it runs, and if you are using it in combination with {{AUR|sbupdate-git}}, ''sbupdate'' expects the {{ic|/boot/efikeys/db.*}} files created by ''cryptboot'' to be capitalized like {{ic|DB.*}} unless otherwise configured in {{ic|/etc/default/sbupdate}}. Users who do not use systemd to handle encryption may not have anything in their {{ic|/etc/crypttab}} file and would need to create an entry.<br />
}}<br />
<br />
Secure Boot implementations use these keys:<br />
<br />
; Platform Key (PK): Top-level key.<br />
; Key Exchange Key (KEK): Keys used to sign Signatures Database and Forbidden Signatures Database updates.<br />
; Signature Database (db): Contains keys and/or hashes of allowed EFI binaries.<br />
; Forbidden Signatures Database (dbx): Contains keys and/or hashes of blacklisted EFI binaries.<br />
<br />
See [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] for a more detailed explanation.<br />
<br />
=== Custom keys ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Creating keys ====<br />
<br />
To generate keys, [[install]] {{Pkg|efitools}}.<br />
<br />
You will need private keys and certificates in multiple formats:<br />
<br />
; ''.key'': PEM format '''private''' keys for EFI binary and EFI signature list signing.<br />
; ''.crt'': PEM format certificates for ''sbsign''.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in EFI Signature List for ''KeyTool'' and/or firmware.<br />
; ''.auth'': Certificates in EFI Signature List with authentication header (i.e. a signed certificate update file) for ''KeyTool'' and/or firmware.<br />
<br />
Create a [[Wikipedia:Globally unique identifier|GUID]] for owner identification:<br />
<br />
$ uuidgen --random > GUID.txt<br />
<br />
Platform key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt<br />
$ openssl x509 -outform DER -in PK.crt -out PK.cer<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth<br />
<br />
Sign an empty file to allow removing Platform Key when in "User Mode":<br />
<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null rm_PK.auth<br />
<br />
Key Exchange Key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt<br />
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth<br />
<br />
Signature Database key:<br />
<br />
$ openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt<br />
$ openssl x509 -outform DER -in db.crt -out db.cer<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth<br />
<br />
==== Updating keys ====<br />
<br />
Once Secure Boot is in "User Mode" any changes to KEK, db and dbx need to be signed with a higher level key.<br />
<br />
For example, if you wanted to replace your db key with a new one:<br />
<br />
# [[#Creating keys|Create the new key]],<br />
# Convert it to EFI Signature List,<br />
# Sign the EFI Signature List,<br />
# Enroll the signed certificate update file.<br />
<br />
$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl<br />
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth<br />
<br />
If instead of replacing your db key, you want to '''add''' another one to the Signature Database, you need to use the option {{ic|-a}} (see {{man|1|sign-efi-sig-list}}):<br />
<br />
$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth<br />
<br />
When {{ic|''new_db''.auth}} is created, [[#Enroll keys in firmware|enroll it]].<br />
<br />
=== Signing bootloader and kernel ===<br />
<br />
{{Tip|The [[rEFInd]] boot manager's {{ic|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.}}<br />
<br />
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]].<br />
<br />
Install {{Pkg|sbsigntools}}.<br />
<br />
{{Note|If running ''sbsign'' without {{ic|--output}} the resulting file will be {{ic|''filename''.signed}}. See {{man|1|sbsign}} for more information.}}<br />
<br />
# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux<br />
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTX64.EFI ''esp''/EFI/BOOT/BOOTX64.EFI<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* You can use {{AUR|sbupdate-git}} 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.<br />
** When using {{AUR|sbupdate-git}}, {{ic|CMDLINE_DEFAULT}} must be set in {{ic|/etc/default/sbupdate}} in order for the ''.efi'' image to be bootable.<br />
** You may want to consider using [[EFISTUB#efibootmgr_with_.efi_file|Direct UEFI boot]] with {{Pkg|efibootmgr}} after generating the signed ''.efi'' file.<br />
}}<br />
<br />
==== Signing kernel with pacman hook ====<br />
<br />
You can also create your own pacman hook to sign kernel on install and updates.<br />
<br />
{{hc|/etc/pacman.d/hooks/99-secureboot.hook|2=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Type = Package<br />
Target = linux<br />
<br />
[Action]<br />
Description = Signing Kernel for SecureBoot<br />
When = PostTransaction<br />
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' \ ;<br />
Depends = sbsigntools<br />
Depends = findutils<br />
Depends = grep<br />
}}<br />
<br />
Since your boot loader or boot manager will also need to be signed, you might want to trigger the hook when the former is updated. Here is an example with systemd-boot:<br />
{{hc|/etc/pacman.d/hooks/99-secureboot.hook|2=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Type = Package<br />
Target = linux<br />
Target = systemd<br />
<br />
[Action]<br />
Description = Signing Kernel for SecureBoot<br />
When = PostTransaction<br />
Exec = /usr/bin/sh -c "/usr/bin/find /boot/ -type f \( -name 'vmlinuz-*' -o -name 'systemd*' \) -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' \;"<br />
Depends = sbsigntools<br />
Depends = findutils<br />
Depends = grep<br />
}}<br />
The {{ic|Target}} needs to be duplicated each time you want to add a new package. Wrt. the {{ic|find}} statement, since we had a condition with the filenames and APLM hooks are being split on spaces, we had to surround the whole statement by quotes in order for the hook to be parsed properly. Since systemd-boot is located in sub-folders, the depth needed to be adjusted as well so that we removed the {{ic|-maxdepth}} argument. In order to avoid hassle, if you are unsure, try to reinstall the package you want to test to see if the hook and signing part are processed successfully. See [[Pacman#Hooks]] or {{man|5|alpm-hooks}} for more info.<br />
<br />
=== Put firmware in "Setup Mode" ===<br />
<br />
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. How to enter the setup utility is described in [[#Before booting the OS]].<br />
<br />
=== Enroll keys in firmware ===<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
Launch firmware setup utility or KeyTool and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<br />
<br />
{{Warning|Enrolling Platform Key sets Secure Boot in "User Mode", leaving "Setup Mode", so it should be enrolled last in sequence.}}<br />
<br />
==== Using firmware setup utility ====<br />
<br />
Firmwares have various different interfaces, see [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] for example how to enroll keys.<br />
<br />
==== Using KeyTool ====<br />
<br />
{{ic|KeyTool.efi}} is in {{Pkg|efitools}} package, copy it to ESP. To use it after enrolling keys, sign it with {{ic|sbsign}}.<br />
<br />
# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi<br />
<br />
Launch {{ic|KeyTool-signed.efi}} using firmware setup utility, boot loader or [[Unified Extensible Firmware Interface#UEFI Shell|UEFI Shell]] and enroll keys.<br />
<br />
See [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] for explanation of KeyTool menu options.<br />
<br />
=== Dual booting with other operating systems ===<br />
<br />
==== Microsoft Windows ====<br />
<br />
{{Expansion|Is it possible to boot Windows by signing its bootloader with a [[#Creating keys|custom key]]?}}<br />
<br />
To [[dual boot with Windows]], you would need to add Microsoft's certificates to the Signature Database. Microsoft has two db certificates:<br />
<br />
* [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011] for Windows<br />
* [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011] for third-party binaries like UEFI drivers, option ROMs etc.<br />
<br />
Microsoft's certificates are in DER format, convert them to PEM format with ''openssl'':<br />
<br />
$ openssl x509 -inform DER -outform PEM -in MicWinProPCA2011_2011-10-19.crt -out MicWinProPCA2011_2011-10-19.crt.pem<br />
$ openssl x509 -inform DER -outform PEM -in MicCorUEFCA2011_2011-06-27.crt -out MicCorUEFCA2011_2011-06-27.crt.pem<br />
<br />
Create EFI Signature Lists with Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicWinProPCA2011_2011-10-19.crt.pem MS_Win_db.esl<br />
$ cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt.pem MS_UEFI_db.esl<br />
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl<br />
<br />
Sign a db update with your KEK. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a db certificate:<br />
<br />
$ 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<br />
<br />
Follow [[#Enroll keys in firmware]] to add {{ic|add_MS_db.auth}} to Signature Database.<br />
<br />
== Disable Secure Boot ==<br />
<br />
The Secure Boot feature can be disabled via the UEFI firmware interface. How to access the firmware configuration is described in [[#Before booting the OS]].<br />
<br />
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''.<br />
<br />
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 [http://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
== Booting an install media ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disable Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. At that time {{pkg|prebootloader}}{{Broken package link|replaced by {{Pkg|efitools}}}} was replaced with {{pkg|efitools}}, even though the later uses unsigned EFI binaries. One might want to [[Remastering the Install ISO|remaster the Install ISO]] in a way described by previous topics of this article. For example, the signed EFI applications {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from [[#PreLoader]] can be adopted to here. Note that up to this point, the article assumed one can access the [[ESP]] of the machine. But when installing a machine that never had an OS before, there is no ESP present. You should explore other articles, for example [[Unified Extensible Firmware Interface#Create UEFI bootable USB from ISO]], to learn how this situation should be handled.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure boot]]<br />
* [http://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] by Rod Smith<br />
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] by Matthew Garrett<br />
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] by James Bottomley<br />
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]<br />
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation<br />
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Free Software Foundation recommendations for free operating system distributions considering Secure Boot]<br />
* [https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]</div>FeedMeWeirdThings