https://wiki.archlinux.org/api.php?action=feedcontributions&user=DasMenschy&feedformat=atomArchWiki - User contributions [en]2024-03-29T04:36:30ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=782436Unified Extensible Firmware Interface/Secure Boot2023-07-03T19:37:22Z<p>DasMenschy: /* Using firmware setup utility */ added some words to make more understandable why you should not copy noPK.auth to the ESP</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Unified Extensible Firmware Interface/Secure Boot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Security}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Unified Extensible Firmware Interface#Secure Boot|Secure Boot]] is a security feature found in the [[UEFI]] standard, designed to add a layer of protection to the [[Arch boot process|pre-boot process]]: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.<br />
<br />
As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|cover]], while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and [[Wikipedia:Unified Extensible Firmware Interface#Secure Boot_2|cons]].<br />
<br />
{{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article and [[#See also|other online resources]]. This article focuses on how to set up Secure Boot in Arch Linux.}}<br />
<br />
== Checking Secure Boot status ==<br />
<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 />
<br />
An easy way to check Secure Boot status on systems using [[systemd]] is to use [[systemd-boot]]:<br />
<br />
{{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}}<br />
<br />
{{hc|$ bootctl status|<br />
System:<br />
Firmware: UEFI 2.70 (American Megatrends 5.15)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
Boot into FW: supported<br />
...<br />
}}<br />
<br />
Here we see that Secure Boot is enabled and enforced; other values are {{ic|disabled}} for Secure Boot and {{ic|setup}} for Setup Mode ([https://github.com/systemd/systemd/issues/8154#issue-296106251 example]).<br />
<br />
Another way to check whether the machine was booted with Secure Boot is to use this command:<br />
<br />
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-*<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 />
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:<br />
<br />
{{hc|# dmesg {{!}} grep -i secure|<br />
[ 0.013442] Secure boot disabled<br />
[ 0.013442] Secure boot could not be determined<br />
}}<br />
<br />
The kernel messages will otherwise read {{ic|Secure boot enabled}}.<br />
<br />
== Booting an installation medium ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disabling Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.<br />
<br />
[https://archboot.com Archboot] images provide a way to use secure boot on installation media.<br />
<br />
=== Disabling 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 and recent Xiaomi laptops) only allow to disable secure boot if you have set an administrator password (that can be removed afterwards). See also [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
=== Remastering the installation image ===<br />
<br />
{{Expansion|Add explicit instructions.}}<br />
<br />
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. Another option would be to borrow the {{ic|BOOTx64.EFI}} (shim) and {{ic|grubx64.efi}} from installation media of another GNU+Linux distribution that supports Secure Boot and modify the GRUB configuration to one's needs. In this case, the authentication chain of Secure Boot in said distribution's installation media should end to the {{ic|grubx64.efi}} ([https://www.linux-magazine.com/index.php/layout/set/print/Issues/2014/164/The-State-of-Secure-Boot/(tagid)/154 for example Ubuntu]) so that GRUB would boot the unsigned kernel and initramfs from archiso. 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 />
== Implementing Secure Boot ==<br />
<br />
There are certain conditions making for an ideal setup of ''Secure boot'':<br />
<br />
# UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]]<br />
# Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/]<br />
# UEFI directly loads a user-signed [[EFISTUB]]-compatible [[unified kernel image]] (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface<br />
# Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.<br />
# Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement.<br />
<br />
A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party.<br />
<br />
=== Using your own keys ===<br />
<br />
{{Warning|Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware ([[Wikipedia:OpROM|OpROMs]]), that get executed during boot, [[#Microsoft Windows|are signed using Microsoft 3rd Party UEFI CA certificate]].}}<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 denylisted 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 />
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 />
==== Backing up current variables ====<br />
<br />
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error.<br />
<br />
Run the following commands to backup all four of the principal Secure Boot variables:<br />
<br />
$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done<br />
<br />
If you perform this command on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft.<br />
<br />
==== Putting 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 />
==== Assisted process with sbctl ====<br />
<br />
[https://github.com/Foxboron/sbctl sbctl] is a user-friendly way of setting up secure boot and signing files.<br />
<br />
{{Note|sbctl does not work with all hardware. How well it will work depends on the manufacturer.}}<br />
<br />
To use it, [[install]] {{Pkg|sbctl}}. See also the [https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] and {{man|8|sbctl}}.<br />
<br />
===== Creating and enrolling keys =====<br />
<br />
Before starting, go to your firmware settings and set secure boot mode to [[#Putting firmware in "Setup Mode"|Setup mode]]. This is different for each device: see {{man|8|sbctl|USAGE}}.<br />
<br />
Once you log back in, check the secure boot status:<br />
<br />
$ sbctl status<br />
<br />
You should see that sbctl is not installed and secure boot is disabled.<br />
<br />
Then create your custom secure boot keys:<br />
<br />
# sbctl create-keys<br />
<br />
Enroll your keys, with Microsoft's keys, to the UEFI:<br />
<br />
# sbctl enroll-keys -m<br />
<br />
{{Warning|Some firmware is signed and verified with Microsoft's keys when secure boot is enabled. Not validating devices could brick them. To enroll your keys without enrolling Microsoft's, run: {{ic|sbctl enroll-keys}}. Only do this if you know what you are doing.}}<br />
<br />
Check the secure boot status again:<br />
<br />
$ sbctl status<br />
<br />
sbctl should be installed now, but secure boot will not work until the boot files have been signed with the keys you just created.<br />
<br />
===== Signing =====<br />
<br />
Check what files need to be signed for secure boot to work:<br />
<br />
# sbctl verify<br />
<br />
Now sign all the unsigned files. Usually the [[kernel]] and the [[boot loader]] need to be signed. For example:<br />
<br />
# sbctl sign -s /boot/vmlinuz-linux<br />
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI<br />
<br />
The files that need to be signed will depend on your system's layout, kernel and boot loader.<br />
<br />
Now you are done! Reboot your system and turn secure boot back on in the firmware settings. If the boot loader and OS load, secure boot should be working. Check with:<br />
<br />
$ sbctl status<br />
<br />
===== Automatic signing with the pacman hook =====<br />
<br />
sbctl comes with a [[pacman hook]] that automatically signs all new files whenever the [[Linux kernel]], [[systemd]] or the [[boot loader]] is updated.<br />
<br />
{{Tip|If you use [[Systemd-boot]] and {{ic|systemd-boot-update.service}}, the [[boot loader]] is only updated after a reboot, and the sbctl [[pacman hook]] will therefore not sign the new file. As a workaround, it can be useful to sign the [[boot loader]] directly in {{ic|/usr/lib/}}, as {{ic|bootctl install}} and {{ic|update}} will automatically recognize and copy ''.efi.signed'' files to the [[ESP]] if present, instead of the normal ''.efi'' file. See {{man|1|bootctl}}.<br />
<br />
# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi<br />
<br />
}}<br />
<br />
==== Manual process ====<br />
<br />
===== Install efitools =====<br />
<br />
Nearly all of the following sections require you to [[install]] the {{Pkg|efitools}} package.<br />
<br />
===== Creating keys =====<br />
<br />
To generate keys, perform the following steps.<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 {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware.<br />
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and 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 noPK.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 />
====== Helper script ======<br />
<br />
A helper/convenience script is offered by the author of the reference page on this topic[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys] (requires [[python]]). A mildly edited version is also packaged as {{AUR|sbkeys}}.<br />
<br />
In order to use it, simply create a folder in a secure location (e.g. {{ic|/etc/efi-keys/}} if later use of {{AUR|sbupdate-git}} to automate unified kernel image creation and signing is planned) and run it:<br />
<br />
# mkdir /etc/efi-keys<br />
# cd !$<br />
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh<br />
# chmod +x mkkeys.sh<br />
# ./mkkeys.sh<br />
''Enter a Common Name to embed in the keys, e.g. "Secure Boot"''<br />
<br />
This will produce the required files in different formats.<br />
<br />
===== Enrolling keys in firmware =====<br />
<br />
Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
{{Tip|As the '''dbx''' (forbidden signatures db) is empty, it can be safely left out in the following instructions.}}<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 sbkeysync ======<br />
<br />
Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure -<br />
<br />
/etc/secureboot/keys<br />
├── db<br />
├── dbx<br />
├── KEK<br />
└── PK<br />
<br />
For example using:<br />
<br />
# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}<br />
<br />
Then copy each of the ''.auth'' files that were generated earlier into their respective locations (for example, {{ic|PK.auth}} into {{ic|/etc/secureboot/keys/PK}} and so on).<br />
<br />
If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use:<br />
<br />
# sbkeysync --pk --dry-run --verbose<br />
<br />
Finally, use {{ic|sbkeysync}} to enroll your keys.<br />
<br />
# sbkeysync --verbose<br />
# sbkeysync --verbose --pk<br />
<br />
{{Tip|1=<nowiki/><br />
* If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}.<br />
* If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}.<br />
* If this fails, it might be due to the firmware locking BIOS settings. On Dell & Lenovo systems, you may need to reset the BIOS password: [https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-firmware-attributes Sysfs Firmware Authentication Documentation]<br />
<br />
On Lenovo systems:<br />
<br />
# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password <br />
my-super-secret-password<br />
<span style="color:#ebf1f5; background-color:#222222;">^D</span><br />
<br />
On Dell systems:<br />
<br />
# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password <br />
my-super-secret-password<br />
<span style="color:#ebf1f5; background-color:#222222;">^D</span><br />
<br />
and try again.<br />
}}<br />
<br />
On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy.<br />
<br />
====== Using firmware setup utility ======<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files ('''except''' the {{ic|noPK.auth}} file!) to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
{{Warning|'''Do not''' copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC! If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with their own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a secret, safe place where only you have access to. A safe place for the noPK.auth file are:<br />
<br />
* an external USB stick with an [[EFI system partition]] when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage.<br />
* [[Data-at-rest encryption|encrypted storage on your PC]] when using {{ic|sbkeysync}}.<br />
The [[EFI system partition]] of your PC must not be encrypted according to the UEFI specifications and can be mounted and read on another PC (if your PC is stolen and if the hard drive is taken out and connected to another PC). Copying the {{ic|noPK.auth}} file to the ESP of your PC and deleting it afterwards is also not advisable, because deleted files on the FAT32 [[EFI system partition]] [[File recovery#TestDisk and PhotoRec|can be recovered with tools like PhotoRec]].<br />
}}<br />
<br />
Launch firmware setup utility and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
Firmwares have various different interfaces, see [https://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 />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<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 [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] for explanation of KeyTool menu options.<br />
<br />
====== Using systemd-boot ======<br />
<br />
Since systemd version 252, [[systemd-boot]] can be used to enroll keys. To enroll keys, copy the {{ic|db.auth}}, {{ic|KEK.auth}} and {{ic|PK.auth}} to the special folder on the ESP:<br />
<br />
# cp db.auth KEK.auth PK.auth ''esp''/loader/keys/''NAME''/<br />
<br />
Where ''NAME'' can be any unique name you assign, such as {{ic|MYKEYS}}.<br />
<br />
After copying the keys and enabling the secure boot setup mode a new entry would appear in the boot menu that would read {{ic|Enroll Secure Boot keys: MYKEYS}}. Activating this entry would enroll the secure boot keys.<br />
<br />
===== Signing EFI binaries =====<br />
<br />
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched.<br />
<br />
====== With sbsigntools ======<br />
<br />
Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}.<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* 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 />
<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 />
To sign your kernel and boot manager use ''sbsign'', e.g.:<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 />
{{Warning|Signing kernel only will not protect the initramfs from tampering. See [[Unified kernel image]] to know how to produce a combined image that you can then manually sign with ''sbsign''.}}<br />
<br />
====== Signing the kernel with a mkinitcpio post hook ======<br />
<br />
You can also use a [[mkinitcpio]] post hook to sign the kernel when the initramfs gets generated.<br />
<br />
[[Create]] the following file an make it [[executable]]:<br />
<br />
{{hc|/etc/initcpio/post/kernel-sbsign|2=<br />
#!/usr/bin/env bash<br />
<br />
kernel="$1"<br />
<nowiki>[[ -n "$kernel" ]] || exit 0<br />
<br />
# use already installed kernel if it exists<br />
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki><br />
<br />
keypairs=(''/path/to/''db.key ''/path/to/''db.crt)<br />
<br />
for (( i=0; i<${#keypairs[@]}; i+=2 )); do<br />
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"<br />
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then<br />
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"<br />
fi<br />
done<br />
}}<br />
<br />
Replace {{ic|''/path/to/''db.key}} and {{ic|''/path/to/''db.crt}} with the paths to the key pair you want to use for signing the kernel.<br />
<br />
If you are using systemd-boot, there is a [[systemd-boot#Automatic update|dedicated pacman hook]] doing this task semi-automatically.<br />
<br />
====== Signing unified kernel images with a mkinitcpio post hook ======<br />
<br />
See [[Unified kernel image#Signing the UKIs for Secure Boot]].<br />
<br />
===== Fully automated unified kernel generation and signing with sbupdate =====<br />
<br />
{{Note|''sbupdate'' was created long before [[mkinitcpio]] and other [[initramfs]] generators acquired the ability to generate [[unified kernel image]]s, providing much appreciated ease to this formerly cumbersome process. Nowadays, consider using instead the [[#Assisted process with sbctl]].<br />
<br />
[https://github.com/andreyv/sbupdate sbupdate] is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through [[pacman hooks]].<br />
<br />
Install {{AUR|sbupdate-git}} and configure it following the instructions given on the project's homepage.[https://github.com/andreyv/sbupdate#sbupdate]<br />
<br />
{{Tip|If using [[systemd-boot]], set {{ic|1=OUT_DIR="EFI/Linux"}} to get your signed kernel images directly recognized without needing configuration. See {{man|7|systemd-boot|FILES}} and [[systemd-boot#Adding loaders]].}}<br />
<br />
Once configured, simply run {{ic|sbupdate}} as root for first-time image generation.<br />
<br />
{{Note|''sbupdate'' output often contains errors such as {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}}. Those are harmless and can be safely ignored.[https://github.com/andreyv/sbupdate/issues/30]}}<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, [[#Enrolling keys in firmware|enroll it]].<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]]?|section=Booting Windows with custom bootloader signature}}<br />
<br />
It is usually '''not''' possible to boot Windows by signing its bootloader ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) with a [[#Creating keys|custom, personal key]] with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables:<br />
<br />
* if {{ic|bootmgfw.efi}} contains a signature '''both''' from the "Microsoft Windows Production PCA 2011" '''and''' from your own Secure Boot DB key (so '''two signatures'''), then UEFI firmware implementations like ''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' will not launch {{ic|bootmgfw.efi}} and will throw a security violation error ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}'''): UEFI firmware implementation like this can probably only read the '''first''' signature - not the '''second''' one. Only the certificate for the second signature is enrolled in the UEFI Secure Boot variables, so the Secure Boot verification fails.<br />
* if the "Microsoft Windows Production PCA 2011" signature from the {{ic|bootmgfw.efi}} file is stripped/removed, and only a signature from your own Secure Boot DB key is added to the file, then UEFI will launch the file - but Windows will launch a recovery/repair environment: Windows complains that the Windows installation is broken (because the "Microsoft Windows Production PCA 2011" signature on {{ic|bootmgfw.efi}} file is missing).<br />
<br />
So to [[dual boot with Windows]],<br />
<br />
* you either have to add the hash of {{ic|bootmgfw.efi}} to the list of allowed hashes in the {{ic|DB}} variable; and you have to update the {{ic|DB}} variable every time a Windows Update changes {{ic|bootmgfw.efi}}. This is very tedious, error-prone and not supported by Microsoft; and for example Bitlocker will not work properly anymore with this setup (Bitlocker will ask for your recovery password every time to decrypt your Windows partition).<br />
* or you have to add Microsoft's certificates to the UEFI Secure Boot variables [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has two {{ic|DB}} certificates and one {{ic|KEK}} certificate]:<br />
** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 certificate] must be included in the {{ic|DB}} variable in order to allow the Windows Operating System to load.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 certificate] aka the Microsoft 3rd Party UEFI CA certificate should be included in the {{ic|DB}} variable in order to use third-party binaries like UEFI drivers, option ROMs, {{Pkg|shim}}, etc.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 certificate] should be included in the {{ic|KEK}} variable, in order to "enable revocation of bad images by updating the {{ic|DBX}} and potentially for updating {{ic|DB}} to prepare for newer Windows signed images". However, Windows will also boot without the "Microsoft Corporation KEK CA 2011" certificate.<br />
<br />
Create EFI Signature Lists from Microsoft's DER format {{ic|DB}} certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt<br />
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl<br />
<br />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format {{ic|KEK}} certificate using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}):<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK.esl MicCorKEKCA2011_2011-06-24.crt<br />
<br />
Sign a {{ic|DB}} variable update with your {{ic|KEK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|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 />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Sign a {{ic|KEK}} variable update with your {{ic|PK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|KEK}} certificate:<br />
<br />
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth<br />
<br />
Follow [[#Enrolling keys in firmware]] to enroll {{ic|add_MS_db.auth}} and for strict conformity with Microsoft UEFI Secure Boot requirements {{ic|add_MS_Win_KEK.auth}} into the UEFI Secure Boot Database variables.<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 an allowlist called Machine Owner Key list, abbreviated MokList. 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 />
{{Warning|What Microsoft calls "Secured-core PCs" do not ship with Microsoft 3rd Party UEFI CA certificate (Microsoft Corporation UEFI CA 2011) enrolled.[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot]. The only enrolled DB certificate is the Microsoft Windows Production PCA 2011 certificate which is exclusively used to sign the Windows boot loader.<br />
<br />
The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate.<br />
}}<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 --unicode --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 --unicode --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 [[#Disabling Secure Boot]].}}<br />
<br />
===== Delete enrolled hash =====<br />
<br />
Every entry of hashes enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hashes to free the space and to prevent outdated programs from booting.<br />
<br />
[[Install]] {{Pkg|efitools}} and copy {{ic|KeyTool.efi}}:<br />
<br />
# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi<br />
<br />
Manage to boot to Preloader and you will see the KeyTool entry. You can then edit hashes in the MOK database.<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|<br />
* 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 />
* Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details.<br />
* It might be worth mentioning that if you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with {{ic|mokutil --disable-validation}}. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows with {{ic|chainloader}} in grub.<br />
}}<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 />
{{Note|<br />
* Make sure you do NOT copy fbx64.efi (which is under the same directory) unless you actually have a valid bootx64.csv to use. Otherwise shim will NOT execute grubx64.efi but will appear to fail to work and just reset the machine.<br />
}}<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 />
Finally, create a new NVRAM entry to boot {{ic|BOOTx64.EFI}}:<br />
<br />
# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI<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 />
Target = linux-lts<br />
Target = linux-hardened<br />
Target = linux-zen<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 />
====== shim with key and GRUB ======<br />
<br />
{{Expansion|[[GRUB#UEFI systems]] mentions a tool called {{ic|grub-mkstandalone}} that is not present here.}}<br />
<br />
{{Merge|GRUB|The details about building your own EFI binary and choosing the modules should probably be in [[GRUB]].}}<br />
<br />
GRUB can only be successfully booted in Secure Boot mode if its EFI binary includes all of the modules necessary to read the filesystem containing the [[vmlinuz]] and [[initramfs]] images.<br />
<br />
Since GRUB version {{ic|2.06.r261.g2f4430cc0}}, loading modules in Secure Boot Mode via {{ic|insmod}} is no longer allowed, as this would violate the expectation to not sideload arbitrary code. If the GRUB modules are not embedded in the EFI binary, and GRUB tries to sideload/{{ic|insmod}} them, GRUB will fail to boot with the message: <br />
<br />
error: prohibited by secure boot policy<br />
<br />
Ubuntu, according to [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12 its official build script], embeds the following GRUB modules in its signed GRUB EFI binary {{ic|grubx64.efi}}: <br />
<br />
* [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n87 the "basic" modules], necessary for booting from a CD or from a simple-partitioned disk: {{ic|all_video}}, {{ic|boot}}, {{ic|btrfs}}, {{ic|cat}}, {{ic|chain}}, {{ic|configfile}}, {{ic|echo}}, {{ic|efifwsetup}}, {{ic|efinet}}, {{ic|ext2}}, {{ic|fat}}, {{ic|font}}, {{ic|gettext}}, {{ic|gfxmenu}}, {{ic|gfxterm}}, {{ic|gfxterm_background}}, {{ic|gzio}}, {{ic|halt}}, {{ic|help}}, {{ic|hfsplus}}, {{ic|iso9660}}, {{ic|jpeg}}, {{ic|keystatus}}, {{ic|loadenv}}, {{ic|loopback}}, {{ic|linux}}, {{ic|ls}}, {{ic|lsefi}}, {{ic|lsefimmap}}, {{ic|lsefisystab}}, {{ic|lssal}}, {{ic|memdisk}}, {{ic|minicmd}}, {{ic|normal}}, {{ic|ntfs}}, {{ic|part_apple}}, {{ic|part_msdos}}, {{ic|part_gpt}}, {{ic|password_pbkdf2}}, {{ic|png}}, {{ic|probe}}, {{ic|reboot}}, {{ic|regexp}}, {{ic|search}}, {{ic|search_fs_uuid}}, {{ic|search_fs_file}}, {{ic|search_label}}, {{ic|sleep}}, {{ic|smbios}}, {{ic|squash4}}, {{ic|test}}, {{ic|true}}, {{ic|video}}, {{ic|xfs}}, {{ic|zfs}}, {{ic|zfscrypt}}, {{ic|zfsinfo}}<br />
* [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n147 the "platform-specific" modules] for x86_64-efi architecture, necessary for e.g.:<br />
** {{ic|play}}: to play sounds during boot<br />
** {{ic|cpuid}}: to the CPU at boot<br />
** {{ic|tpm}}: to support Measured Boot / [[TPM|Trusted Platform Modules]]<br />
* [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n159 the "advanced" modules], consisting of modules:<br />
** {{ic|cryptodisk}}: to boot from [[dm-crypt|plain-mode encrypted]] disks<br />
** {{ic|gcry_''algorithm''}}: to support particular hashing and encryption algorithms<br />
** {{ic|luks}}: to boot from [[LUKS]]-encrypted disks:<br />
** {{ic|lvm}}: to boot from [[LVM]] logical volume disks<br />
** {{ic|mdraid09}}, {{ic|mdraid1x}}, {{ic|raid5rec}}, {{ic|raid6rec}}: to boot from [[RAID]] virtual disks<br />
<br />
You must construct your list of GRUB modules in the form of a shell variable that we denote as {{ic|GRUB_MODULES}}. You can use the [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images latest Ubuntu script] as a starting point, and trim away modules that are not necessary on your system. Omitting modules will make the boot process relatively faster, and save some space on the ESP partition.<br />
<br />
You also need a [https://github.com/rhboot/shim/blob/main/SBAT.md Secure Boot Advanced Targeting (SBAT)] file/section included in the EFI binary, to improve the security; if GRUB is launched from the UEFI shim loader. This SBAT file/section contains metadata about the GRUB binary (version, maintainer, developer, upstream URL) and makes it easier for shim to block certain GRUB versions from being loaded if they have security vulnerabilities[https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#additional][https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021], as explained in the [https://github.com/rhboot/shim/blob/main/SBAT.md UEFI shim bootloader secure boot life-cycle improvements] document from shim. <br />
<br />
The first-stage UEFI bootloader shim will fail to launch {{ic|grubx64.efi}} if the SBAT section from {{ic|grubx64.efi}} is missing! <br />
<br />
If GRUB is installed, a sample SBAT ''.csv'' file is provided under {{ic|/usr/share/grub/sbat.csv}}. <br />
<br />
Reinstall GRUB using the provided {{ic|/usr/share/grub/sbat.csv}} file and all the needed {{ic|GRUB_MODULES}} and sign it:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
# cp ''esp''/GRUB/grubx64.efi ''esp''/boot/grubx64.efi<br />
<br />
Reboot, select the key in ''MokManager'', and Secure Boot should be working.<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 />
== Protecting Secure Boot ==<br />
<br />
The only way to prevent anyone with physical access from disabling Secure Boot is to protect the firmware settings with a password. Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.<br />
<br />
Consider enabling [[Security#Kernel lockdown mode|kernel lockdown mode]]. See [https://stackoverflow.com/a/60104165].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Sign the official ISO with custom keys ===<br />
<br />
Support for Secure Boot using custom keys can be added to the official ISO by simply extracting the boot loader ({{ic|BOOTx64.EFI}} and {{ic|BOOTIA32.EFI}}), kernel, UEFI shell, signing them and then repacking the ISO with the signed files.<br />
<br />
[[Install]] {{Pkg|libisoburn}}, {{Pkg|mtools}} and {{Pkg|sbsigntools}}.<br />
<br />
First extract the relevant files and El Torito boot images:<br />
<br />
{{bc|<br />
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \<br />
-extract_boot_images ./ \<br />
-cpx /arch/boot/x86_64/vmlinuz-linux \<br />
/EFI/BOOT/BOOTx64.EFI \<br />
/EFI/BOOT/BOOTIA32.EFI \<br />
/shellx64.efi \<br />
/shellia32.efi ./<br />
}}<br />
<br />
{{man|1|xorrisofs}} option {{ic|-rational-rock}} as used by ''mkarchiso'' makes the files on ISO 9660 read-only which persists after extracting them. Make the files writable so that they can be modified:<br />
<br />
$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux<br />
<br />
Sign the files using an enrolled db key and certificate:<br />
<br />
$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI<br />
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI<br />
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi<br />
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi<br />
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux<br />
<br />
Copy the boot loader and UEFI shell to {{ic|eltorito_img2_uefi.img}}. It will be used as the EFI system partition and will be listed as an El Torito UEFI boot image. The size of {{ic|eltorito_img2_uefi.img}} is fixed, but there is 1 MiB free space added by ''mkarchiso'' for the purposes of rounding/alignment and to account for reserved sectors, so the size increase from the signatures should not be an issue.<br />
<br />
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/<br />
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/<br />
<br />
Repack the ISO using the modified El Torito UEFI boot image and add the signed boot loader files, UEFI shell and<br />
kernel to ISO 9660:<br />
<br />
{{bc|<br />
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \<br />
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \<br />
-boot_image any replay \<br />
-append_partition 2 0xef eltorito_img2_uefi.img \<br />
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \<br />
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \<br />
-map_l ./ / shellx64.efi shellia32.efi<br />
}}<br />
<br />
Boot the resulting {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}}.<br />
<br />
== See also ==<br />
<br />
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure Boot]]<br />
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [https://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://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]<br />
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]<br />
* National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]<br />
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr<br />
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)<br />
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)<br />
* [http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] by Lennart Poettering (2021-09-23)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=752192Talk:Unified Extensible Firmware Interface/Secure Boot2022-10-11T13:32:58Z<p>DasMenschy: /* Section "Shim with key and GRUB" */ different setup with refind/systemdboot</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
:I personally had many more digits, but that's because the <code>SecureBoot*</code> glob matches a <code>SecureBootSetup-...</code> file. If I use <code>SecureBoot-*</code> (note the dash), I get the expected output (secure boot is disabled on my system):<br />
<nowiki>od -An -tu1 /sys/firmware/efi/efivars/SecureBoot-*<br />
6 0 0 0 0</nowiki><br />
:--[[User:PsYchotic|PsYchotic]] ([[User talk:PsYchotic|talk]]) 18:53, 1 June 2022 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
:::Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.<br />
:::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).<br />
:::About the {{ic|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.<br />
:::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?<br />
:::[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 02:17, 22 December 2021 (UTC)<br />
<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
: The current warning isn't much help in finding out if one's device is going to be affected. Is [https://github.com/Foxboron/sbctl/wiki/FAQ this] reliable enough to be added to the wiki as a possible check ? --[[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 21:44, 30 December 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)<br />
:: There isn't any easy tools for doing any of this which is why I started writing [https://github.com/Foxboron/sbctl sbctl]]. However I'm not super comfortable adding it to Arch Wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 19:44, 2 January 2022 (UTC)<br />
:::: 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.<br />
:::: [[User:Kiasoc5|Kiasoc5]] ([[User talk:Kiasoc5|talk]]) 19:16, 16 May 2022 (UTC)<br />
<br />
== about restoring OEM keys ==<br />
This is a little off-topic, but:<br />
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<br />
<br />
{{unsigned|14:12, 5 August 2022|Solstice}}<br />
: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? <br />
:* Option 1: At the end of section [[Secure Boot#Using your own keys|"3.1 Using your own keys"]], just after [[Secure Boot#Dual booting with other operating systems|"3.1.7 Dual booting with other operating systems"]], a section: '''"3.1.8 Restoring the OEM Secure Boot variables"'''?<br />
:* Option 2: Or included in the section [[Secure Boot#Backing up current variables|"3.1.2 Backing up current variables"]]? <br />
:[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:27, 5 August 2022 (UTC)<br />
<br />
== Section "Shim with key and GRUB" ==<br />
<br />
Concerning the section [[Unified Extensible Firmware Interface/Secure Boot#Shim with key and GRUB]]: <br />
<br />
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 [https://www.linux.org/threads/understanding-the-various-grub-modules.11142/ this thread on linux.org], which doesn't have all modules however and is already outdated. <br />
The [https://www.gnu.org/software/grub/manual/grub/grub.html official GNU GRUB manual] has '''no documentation at all''' about the modules. <br />
<br />
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?<br />
<br />
Thank you in advance for help! <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 12:42, 28 August 2022 (UTC)<br />
<br />
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 [[User:Blaatschaap|Blaatschaap]] ([[User talk: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 [[User:Blaatschaap|Blaatschaap]] ([[User talk:Blaatschaap|talk]]) 12:55, 11 October 2022 (UTC)<br />
<br />
: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. <br />
<br />
: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. <br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:06, 11 October 2022 (UTC)<br />
<br />
::Hardcoding "grubx64.efi" into the shim binary does not offer any security benefit, but makes life harder for everyone. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:13, 11 October 2022 (UTC)<br />
<br />
::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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:13, 11 October 2022 (UTC)<br />
<br />
I think the best way is to replace grub with <br />
* refind or <br />
* systemdboot <br />
and then rename the <br />
* "refindx64.efi" or <br />
* "systemdbootx64.efi" <br />
... file to "grubx64.efi", so that shim can launch them. The <br />
* refind-install-script or <br />
* systemdboot-install-script <br />
... should then also drop a file in the grubx64.efi directory, explaining that the grubx64.efi file is not grub, like so: <br />
* "grubx64-efi-is-not-grub-but-refind.txt" or <br />
* "grubx64-efi-is-not-grub-but-systemdboot.txt" <br />
<br />
:: <br />
* refind or <br />
* systemdboot <br />
... 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. <br />
<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:28, 11 October 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=752191Talk:Unified Extensible Firmware Interface/Secure Boot2022-10-11T13:28:20Z<p>DasMenschy: /* Section "Shim with key and GRUB" */ Explain a different setup where refind or systemdboot replace grub.</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
:I personally had many more digits, but that's because the <code>SecureBoot*</code> glob matches a <code>SecureBootSetup-...</code> file. If I use <code>SecureBoot-*</code> (note the dash), I get the expected output (secure boot is disabled on my system):<br />
<nowiki>od -An -tu1 /sys/firmware/efi/efivars/SecureBoot-*<br />
6 0 0 0 0</nowiki><br />
:--[[User:PsYchotic|PsYchotic]] ([[User talk:PsYchotic|talk]]) 18:53, 1 June 2022 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
:::Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.<br />
:::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).<br />
:::About the {{ic|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.<br />
:::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?<br />
:::[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 02:17, 22 December 2021 (UTC)<br />
<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
: The current warning isn't much help in finding out if one's device is going to be affected. Is [https://github.com/Foxboron/sbctl/wiki/FAQ this] reliable enough to be added to the wiki as a possible check ? --[[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 21:44, 30 December 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)<br />
:: There isn't any easy tools for doing any of this which is why I started writing [https://github.com/Foxboron/sbctl sbctl]]. However I'm not super comfortable adding it to Arch Wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 19:44, 2 January 2022 (UTC)<br />
:::: 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.<br />
:::: [[User:Kiasoc5|Kiasoc5]] ([[User talk:Kiasoc5|talk]]) 19:16, 16 May 2022 (UTC)<br />
<br />
== about restoring OEM keys ==<br />
This is a little off-topic, but:<br />
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<br />
<br />
{{unsigned|14:12, 5 August 2022|Solstice}}<br />
: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? <br />
:* Option 1: At the end of section [[Secure Boot#Using your own keys|"3.1 Using your own keys"]], just after [[Secure Boot#Dual booting with other operating systems|"3.1.7 Dual booting with other operating systems"]], a section: '''"3.1.8 Restoring the OEM Secure Boot variables"'''?<br />
:* Option 2: Or included in the section [[Secure Boot#Backing up current variables|"3.1.2 Backing up current variables"]]? <br />
:[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:27, 5 August 2022 (UTC)<br />
<br />
== Section "Shim with key and GRUB" ==<br />
<br />
Concerning the section [[Unified Extensible Firmware Interface/Secure Boot#Shim with key and GRUB]]: <br />
<br />
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 [https://www.linux.org/threads/understanding-the-various-grub-modules.11142/ this thread on linux.org], which doesn't have all modules however and is already outdated. <br />
The [https://www.gnu.org/software/grub/manual/grub/grub.html official GNU GRUB manual] has '''no documentation at all''' about the modules. <br />
<br />
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?<br />
<br />
Thank you in advance for help! <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 12:42, 28 August 2022 (UTC)<br />
<br />
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 [[User:Blaatschaap|Blaatschaap]] ([[User talk: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 [[User:Blaatschaap|Blaatschaap]] ([[User talk:Blaatschaap|talk]]) 12:55, 11 October 2022 (UTC)<br />
<br />
: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. <br />
<br />
: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. <br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:06, 11 October 2022 (UTC)<br />
<br />
::Hardcoding "grubx64.efi" into the shim binary does not offer any security benefit, but makes life harder for everyone. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:13, 11 October 2022 (UTC)<br />
<br />
::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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:13, 11 October 2022 (UTC)<br />
<br />
::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". <br />
<br />
refind or systemdboot can then launch the Unified kernel image files. I think this approach is a bit more meaningful. <br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:28, 11 October 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=752190Talk:Unified Extensible Firmware Interface/Secure Boot2022-10-11T13:13:02Z<p>DasMenschy: /* Section "Shim with key and GRUB" */ add some more comments</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
:I personally had many more digits, but that's because the <code>SecureBoot*</code> glob matches a <code>SecureBootSetup-...</code> file. If I use <code>SecureBoot-*</code> (note the dash), I get the expected output (secure boot is disabled on my system):<br />
<nowiki>od -An -tu1 /sys/firmware/efi/efivars/SecureBoot-*<br />
6 0 0 0 0</nowiki><br />
:--[[User:PsYchotic|PsYchotic]] ([[User talk:PsYchotic|talk]]) 18:53, 1 June 2022 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
:::Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.<br />
:::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).<br />
:::About the {{ic|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.<br />
:::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?<br />
:::[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 02:17, 22 December 2021 (UTC)<br />
<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
: The current warning isn't much help in finding out if one's device is going to be affected. Is [https://github.com/Foxboron/sbctl/wiki/FAQ this] reliable enough to be added to the wiki as a possible check ? --[[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 21:44, 30 December 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)<br />
:: There isn't any easy tools for doing any of this which is why I started writing [https://github.com/Foxboron/sbctl sbctl]]. However I'm not super comfortable adding it to Arch Wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 19:44, 2 January 2022 (UTC)<br />
:::: 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.<br />
:::: [[User:Kiasoc5|Kiasoc5]] ([[User talk:Kiasoc5|talk]]) 19:16, 16 May 2022 (UTC)<br />
<br />
== about restoring OEM keys ==<br />
This is a little off-topic, but:<br />
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<br />
<br />
{{unsigned|14:12, 5 August 2022|Solstice}}<br />
: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? <br />
:* Option 1: At the end of section [[Secure Boot#Using your own keys|"3.1 Using your own keys"]], just after [[Secure Boot#Dual booting with other operating systems|"3.1.7 Dual booting with other operating systems"]], a section: '''"3.1.8 Restoring the OEM Secure Boot variables"'''?<br />
:* Option 2: Or included in the section [[Secure Boot#Backing up current variables|"3.1.2 Backing up current variables"]]? <br />
:[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:27, 5 August 2022 (UTC)<br />
<br />
== Section "Shim with key and GRUB" ==<br />
<br />
Concerning the section [[Unified Extensible Firmware Interface/Secure Boot#Shim with key and GRUB]]: <br />
<br />
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 [https://www.linux.org/threads/understanding-the-various-grub-modules.11142/ this thread on linux.org], which doesn't have all modules however and is already outdated. <br />
The [https://www.gnu.org/software/grub/manual/grub/grub.html official GNU GRUB manual] has '''no documentation at all''' about the modules. <br />
<br />
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?<br />
<br />
Thank you in advance for help! <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 12:42, 28 August 2022 (UTC)<br />
<br />
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 [[User:Blaatschaap|Blaatschaap]] ([[User talk: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 [[User:Blaatschaap|Blaatschaap]] ([[User talk:Blaatschaap|talk]]) 12:55, 11 October 2022 (UTC)<br />
<br />
: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. <br />
<br />
: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. <br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:06, 11 October 2022 (UTC)<br />
<br />
::Hardcoding "grubx64.efi" into the shim binary does not offer any security benefit, but makes life harder for everyone. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:13, 11 October 2022 (UTC)<br />
<br />
::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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:13, 11 October 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=752189Talk:Unified Extensible Firmware Interface/Secure Boot2022-10-11T13:06:31Z<p>DasMenschy: /* Section "Shim with key and GRUB" */ Answer why shim + Unified kernel image way is not such a good idea</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
:I personally had many more digits, but that's because the <code>SecureBoot*</code> glob matches a <code>SecureBootSetup-...</code> file. If I use <code>SecureBoot-*</code> (note the dash), I get the expected output (secure boot is disabled on my system):<br />
<nowiki>od -An -tu1 /sys/firmware/efi/efivars/SecureBoot-*<br />
6 0 0 0 0</nowiki><br />
:--[[User:PsYchotic|PsYchotic]] ([[User talk:PsYchotic|talk]]) 18:53, 1 June 2022 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
:::Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.<br />
:::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).<br />
:::About the {{ic|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.<br />
:::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?<br />
:::[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 02:17, 22 December 2021 (UTC)<br />
<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
: The current warning isn't much help in finding out if one's device is going to be affected. Is [https://github.com/Foxboron/sbctl/wiki/FAQ this] reliable enough to be added to the wiki as a possible check ? --[[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 21:44, 30 December 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)<br />
:: There isn't any easy tools for doing any of this which is why I started writing [https://github.com/Foxboron/sbctl sbctl]]. However I'm not super comfortable adding it to Arch Wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 19:44, 2 January 2022 (UTC)<br />
:::: 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.<br />
:::: [[User:Kiasoc5|Kiasoc5]] ([[User talk:Kiasoc5|talk]]) 19:16, 16 May 2022 (UTC)<br />
<br />
== about restoring OEM keys ==<br />
This is a little off-topic, but:<br />
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<br />
<br />
{{unsigned|14:12, 5 August 2022|Solstice}}<br />
: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? <br />
:* Option 1: At the end of section [[Secure Boot#Using your own keys|"3.1 Using your own keys"]], just after [[Secure Boot#Dual booting with other operating systems|"3.1.7 Dual booting with other operating systems"]], a section: '''"3.1.8 Restoring the OEM Secure Boot variables"'''?<br />
:* Option 2: Or included in the section [[Secure Boot#Backing up current variables|"3.1.2 Backing up current variables"]]? <br />
:[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:27, 5 August 2022 (UTC)<br />
<br />
== Section "Shim with key and GRUB" ==<br />
<br />
Concerning the section [[Unified Extensible Firmware Interface/Secure Boot#Shim with key and GRUB]]: <br />
<br />
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 [https://www.linux.org/threads/understanding-the-various-grub-modules.11142/ this thread on linux.org], which doesn't have all modules however and is already outdated. <br />
The [https://www.gnu.org/software/grub/manual/grub/grub.html official GNU GRUB manual] has '''no documentation at all''' about the modules. <br />
<br />
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?<br />
<br />
Thank you in advance for help! <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 12:42, 28 August 2022 (UTC)<br />
<br />
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 [[User:Blaatschaap|Blaatschaap]] ([[User talk: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 [[User:Blaatschaap|Blaatschaap]] ([[User talk:Blaatschaap|talk]]) 12:55, 11 October 2022 (UTC)<br />
<br />
: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. <br />
<br />
: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. <br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 13:06, 11 October 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Plymouth&diff=748570Talk:Plymouth2022-09-26T15:03:20Z<p>DasMenschy: /* "Secure Boot disabled" plymouth warning - available starting with GNOME 43 */ new section</p>
<hr />
<div>== AGP module not loaded before graphics module when using plymouth hook ==<br />
<br />
I was getting a "[drm:radeon_agp_init [radeon]] *ERROR* unable to acquire AGP: -19" error at boot, after "starting version 219" and before plymouth took over the screen when following the instructions.<br />
E.g. hooks="base udev plymouth ...", despite having modules="via_agp radeon ...".<br />
<br />
Not sure if it's a problem with the current plymouth hook but I removed it from mkinitcpio.conf, rebuilt initramfs and the error goes away -and- I still have plymouth on boot. --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 21:13, 21 May 2015 (UTC)<br />
<br />
== ShowDelay=5 ==<br />
<br />
/etc/plymouth/plymouthd.conf<br />
[Daemon]<br />
Theme=spinner<br />
ShowDelay=0 <br />
<br />
delay 5 is for a long time kde<br />
<br />
{{unsigned|03:23, 2 November 2018|Rzax666}}<br />
<br />
== The cryptdevice kernel parameter does work? ==<br />
<br />
The wiki currently states that:<br />
<br />
{{Warning|<br />
* Using {{ic|PARTUUID}} or {{ic|PARTLABEL}} in {{ic|1=cryptdevice=}} parameter does '''not''' work with {{ic|plymouth-encrypt}} hook.<br />
}}<br />
<br />
However, my encrypted system boots with:<br />
options "cryptdevice=UUID=deadbeef-dead-beef-dead-deadbeefbeef lvm root=/dev/mapper/foobar rw add_efi_memmap quiet loglevel=3 rd.udev.log_priority=3 vt.global_cursor_default=0 splash acpi_osi=""!Windows 2015"" initrd=\EFI\arch\intel-ucode.img initrd=\EFI\arch\initramfs-linux.img"<br />
<br />
This implies that it does work<br />
<br />
[[User:Shoaloak|Shoaloak]] ([[User talk:Shoaloak|talk]]) 20:44, 17 June 2020 (UTC)<br />
<br />
:No, UUID is not the same thing as PARTUUID. See [[Persistent block device naming]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:52, 17 June 2020 (UTC)<br />
<br />
== FlickerFreeBoot ==<br />
<br />
Fedora had made some work on FilckerFreeBoot. Here are some usable url:<br />
<br />
* [https://fedoraproject.org/wiki/Changes/FlickerFreeBoot FlickerFreeBoot]<br />
* [https://hansdegoede.livejournal.com/19224.html Announcing flickerfree boot for Fedora 29]<br />
* [https://hansdegoede.livejournal.com/20632.html Flicker Free Boot FAQ] <br />
* [https://kernelnewbies.org/Linux_5.8#Core_.28various.29 Linux5.8]<br />
* [https://kernelnewbies.org/Linux_4.18?action=fullsearch&context=180&value=video#Drivers Linux4.18]<br />
<br />
Let's we bring this to ArchLinux :)<br />
<br />
{{Unsigned|13:14, 10 May 2021 (UTC)|Dragonwater}}<br />
<br />
Now I can say, the command [[Plymouth|The kernel command line]] is too long, "quiet splash" just be needed for me. <br />
<br />
And far, the command "video=efifb:nobgrt" can be used to hidden vendor logo [[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 13:34, 10 May 2021 (UTC)<br />
<br />
== ShowDelay: "The default is 5 seconds" ==<br />
<br />
The default for me ({{AUR|plymouth-git}}):<br />
<br />
{{hc|<br />
head=/etc/plymouth/plymouthd.conf<br />
|<br />
output=<br />
# Set your plymouth configuration here.<br />
[Daemon]<br />
Theme=spinner<br />
ShowDelay=0<br />
DeviceTimeout=8<br />
}}<br />
<br />
Can someone else confirm this?<br />
[[User:Glibg10b|Glibg10b]] ([[User talk:Glibg10b|talk]]) 17:21, 14 May 2021 (UTC)<br />
<br />
== Plymouth is not necessary for flicker-free boot ==<br />
<br />
It could be worth mentioning that Plymouth is not always necessary for a flicker free-boot.<br />
Following the steps in [[Unified kernel image]] and setting {{ic|bgrt_disable}} kernel parameter achieves the same result, as long as you don't have to enter any passphrase (no encryption, or disk decrypted with keyfile..). I didn't test it but it might even work when using an encrypted boot partition with Grub, since the password is entered before anything else is done.<br />
<br />
-- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 00:06, 31 December 2021 (UTC)<br />
<br />
== "Secure Boot disabled" plymouth warning - available starting with GNOME 43 ==<br />
<br />
The plymouth developers [https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/176 are working on] a warning that should be displayed during boot if Secure Boot is disabled (and especially if LUKS encryption is enabled and a password should be requested). Secure Boot and this warning should prevent '''keyloggers''' from getting the [[LUKS]] password. <br />
At the moment however, '''no warning will be shown''', although the "Secure Boot warning" functionality is already included in the latest {{aur|plymouth-git}} version 22.02.122. The Secure Boot warning functionality is disabled. <br />
This is because the plymouth developers are '''waiting''' until the "Secure Boot warning" functionality is '''also''' implemented in the future version 43 of {{Grp|gnome}}; [https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2333 as can be seen in the last comment of this merge request]: <br />
We were talking to @aday about this last week, we don't really want to enable the plymouth feature until the GDM feature is also confirmed; it'd be really confusing to just see the red icon in plymouth without the explanation of what it means in gdm too. - Richard Hughes @hughsie · 1 month ago <br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 15:03, 26 September 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=User_talk:Scimmia&diff=747755User talk:Scimmia2022-09-22T14:23:49Z<p>DasMenschy: /* GRUB */ Fix heading</p>
<hr />
<div>== Changes in grub regarding addition of '/boot' to configuration files. ==<br />
<br />
When you reverted my changes, you mentioned<br />
"This isn't a 'keyword', it's part of the path, which is relative to the volume it's on. This is already explained above when set root= is mentioned."<br />
I agree with the correction on the '''keyword''' part but where is the '''explanation''' you mentioned? Ic ouldn't find it.<br />
<br />
:As I said, it's when you 'set root='. Specifically when it says "set root=(hdX,Y) sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition (/)" As that's the partition you're working on, paths are pretty much common sense from there.<br />
<br />
::If common sense is considered, the Arch wiki would be much shorter. But then again what seems like commmon sense to us might not be for new users. In the GRUB wiki page itself under, [[GRUB#Encrypted_/boot|Encrypted_/boot]], the tip I mentioned regarding {{ic|/boot}} in path is mentioned. But I suggest to add it in more places especially tthe [https://wiki.archlinux.org/title/GRUB#Custom_grub.cfg Custom_grub.cfg] section becuase incorrect configuration will lead to unbootable systems. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 05:40, 25 March 2022 (UTC)<br />
<br />
:::No, the tip you mentioned regarding /boot is NOT in the Encrypted_/boot section.<br />
:::You keep saying how this could lead to an unbootable system; yeah, so what? If you screw up a config, it doesn't work, that's pretty normal and this situation is not special.<br />
:::If you want to expand the 'set root=' part a bit and say that all paths are relative to this, that can make sense. The tip as you had it did not.<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 12:11, 25 March 2022 (UTC)<br />
::::The section I was talking about was wrong. Sorry for that. The actual one is this [[GRUB#Using_the_rescue_console]]. This has multiple notes on the {{ic|/boot}} prefix. Expanding the 'set root=' part and saying about relative paths is a relatively complicated way of saying the same thing as the tip/note I had provided. So, it doesn't really make any sense and I would rather avoid that. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 12:27, 25 March 2022 (UTC)<br />
<br />
== [[GRUB]] ==<br />
<br />
There are no instructions at all that really document how to setup Secure Boot with GRUB and verified initrds, so I thought that at least some third-party instructions would be nice (even if they don't work). I wanted to add this note as a warning for other people so they don't even start the instructions on that website (because they will inevitably fail). <br />
The instructions on that Third-party page have a lot to do with the Wiki page: they are about GRUB as well. I don't think it's fair that you removed my paragraph. Could you maybe re-include it, please? [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 14:17, 22 September 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=User_talk:Scimmia&diff=747754User talk:Scimmia2022-09-22T14:17:16Z<p>DasMenschy: /* GRUB */ new section</p>
<hr />
<div>== Changes in grub regarding addition of '/boot' to configuration files. ==<br />
<br />
When you reverted my changes, you mentioned<br />
"This isn't a 'keyword', it's part of the path, which is relative to the volume it's on. This is already explained above when set root= is mentioned."<br />
I agree with the correction on the '''keyword''' part but where is the '''explanation''' you mentioned? Ic ouldn't find it.<br />
<br />
:As I said, it's when you 'set root='. Specifically when it says "set root=(hdX,Y) sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition (/)" As that's the partition you're working on, paths are pretty much common sense from there.<br />
<br />
::If common sense is considered, the Arch wiki would be much shorter. But then again what seems like commmon sense to us might not be for new users. In the GRUB wiki page itself under, [[GRUB#Encrypted_/boot|Encrypted_/boot]], the tip I mentioned regarding {{ic|/boot}} in path is mentioned. But I suggest to add it in more places especially tthe [https://wiki.archlinux.org/title/GRUB#Custom_grub.cfg Custom_grub.cfg] section becuase incorrect configuration will lead to unbootable systems. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 05:40, 25 March 2022 (UTC)<br />
<br />
:::No, the tip you mentioned regarding /boot is NOT in the Encrypted_/boot section.<br />
:::You keep saying how this could lead to an unbootable system; yeah, so what? If you screw up a config, it doesn't work, that's pretty normal and this situation is not special.<br />
:::If you want to expand the 'set root=' part a bit and say that all paths are relative to this, that can make sense. The tip as you had it did not.<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 12:11, 25 March 2022 (UTC)<br />
::::The section I was talking about was wrong. Sorry for that. The actual one is this [[GRUB#Using_the_rescue_console]]. This has multiple notes on the {{ic|/boot}} prefix. Expanding the 'set root=' part and saying about relative paths is a relatively complicated way of saying the same thing as the tip/note I had provided. So, it doesn't really make any sense and I would rather avoid that. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 12:27, 25 March 2022 (UTC)<br />
<br />
== GRUB ==<br />
<br />
There are no instructions at all that really document how to setup Secure Boot with GRUB and verified initrds, so I thought that at least some third-party instructions would be nice (even if they don't work). I wanted to add this note as a warning for other people so they don't even start the instructions on that website (because they will inevitably fail). <br />
The instructions on that Third-party page have a lot to do with the Wiki page: they are about GRUB as well. I don't think it's fair that you removed my paragraph. Could you maybe re-include it, please? [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 14:17, 22 September 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=GRUB&diff=747750GRUB2022-09-22T14:00:12Z<p>DasMenschy: /* Installation */ GRUB Secure Boot setup with GPG keys (that verify the kernel and initrd's) doesn't work because the verify GRUB2 module does not exist anymore.</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[Category:GNU]]<br />
[[de:GRUB]]<br />
[[es:GRUB]]<br />
[[fa:گراب]]<br />
[[ja:GRUB]]<br />
[[pt:GRUB]]<br />
[[ru:GRUB]]<br />
[[zh-hans:GRUB]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|/EFI examples}}<br />
{{Related|/Tips and tricks}}<br />
{{Related|Multiboot USB drive}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] (GRand Unified Bootloader) is a [[boot loader]]. The current GRUB is also referred to as '''GRUB 2'''. The original GRUB, or [[GRUB Legacy]], corresponds to versions 0.9x. This page exclusively describes GRUB 2.<br />
<br />
{{Note|In the entire article {{ic|''esp''}} denotes the mountpoint of the [[EFI system partition]] aka ESP.}}<br />
<br />
== UEFI systems ==<br />
<br />
{{Note|<br />
* It is recommended to read and understand the [[Unified Extensible Firmware Interface]], [[Partitioning#GUID Partition Table]] and [[Arch boot process#Under UEFI]] pages.<br />
* When installing to use UEFI it is important to boot the installation media in UEFI mode, otherwise ''efibootmgr'' will not be able to add the GRUB UEFI boot entry. Installing to the [[#Default/fallback boot path|fallback boot path]] will still work even in BIOS mode since it does not touch the NVRAM.<br />
* To boot from a disk using UEFI, an EFI system partition is required. Follow [[EFI system partition#Check for an existing partition]] to find out if you have one already, otherwise you need to create it.<br />
}}<br />
{{Warning|This whole article assumes that inserting additional GRUB2 modules via {{ic|insmod}} is possible. This is not the case however with newer GRUB2 versions on UEFI systems where Secure Boot is enabled - Secure Boot should block sideloading any arbitrary code, which also means GRUB2 modules. If Secure Boot is enabled, {{ic|insmod ...}} will most likely fail and throw out a security violation. If you want to use any additional GRUB module that is not included in the standard GRUB EFI file {{ic|grubx64.efi}} on systems where Secure Boot is enabled, you have to re-generate the GRUB EFI {{ic|grubx64.efi}} with {{ic|grub-mkstandalone}} with the additional GRUB modules included.}}<br />
<br />
=== Installation ===<br />
<br />
{{Note|<br />
* UEFI firmwares are not implemented consistently across manufacturers. The procedure described below is intended to work on a wide range of UEFI systems but those experiencing problems despite applying this method are encouraged to share detailed information, and if possible the workarounds found, for their hardware-specific case. A [[/EFI examples]] article has been provided for such cases.<br />
* The section assumes you are installing GRUB for x86_64 systems. For IA32 (32-bit) UEFI systems (not to be confused with 32-bit CPUs), replace {{ic|x86_64-efi}} with {{ic|i386-efi}} where appropriate.<br />
* See [[Secure Boot]] for instructions on implementing it. <br />
}}<br />
{{Note|The instructions on [https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd ruderich.org] from year 2016, describing how to setup "Secure Boot with GRUB 2 and signed Linux images and initrds" with GPG keys on UEFI systems, don't work anymore as of September 2022, because the mentioned {{ic|verify.mod}} GRUB2 module does not exist anymore, as can be seen from the list of files provided by the [https://archlinux.org/packages/core/x86_64/grub/ grub package].}}<br />
<br />
<br />
First, [[install]] the packages {{Pkg|grub}} and {{Pkg|efibootmgr}}: ''GRUB'' is the bootloader while ''efibootmgr'' is used by the GRUB installation script to write boot entries to NVRAM. <br />
<br />
Then follow the below steps to install GRUB to your disk:<br />
<br />
# [[EFI system partition#Mount the partition|Mount the EFI system partition]] and in the remainder of this section, substitute {{ic|''esp''}} with its mount point.<br />
# Choose a bootloader identifier, here named {{ic|GRUB}}. A directory of that name will be created in {{ic|''esp''/EFI/}} to store the EFI binary and this is the name that will appear in the UEFI boot menu to identify the GRUB boot entry.<br />
# Execute the following command to install the GRUB EFI application {{ic|grubx64.efi}} to {{ic|''esp''/EFI/GRUB/}} and install its modules to {{ic|/boot/grub/x86_64-efi/}}. {{Note|Make sure to install the packages and run the {{ic|grub-install}} command from the system in which GRUB will be installed as the boot loader. That means if you are booting from the live installation environment, you need to be inside the chroot when running {{ic|grub-install}}. If for some reason it is necessary to run {{ic|grub-install}} from outside of the installed system, append the {{ic|1=--boot-directory=}} option with the path to the mounted {{ic|/boot}} directory, e.g {{ic|1=--boot-directory=/mnt/boot}}.}} {{bc|1=# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB}}<br />
<br />
After the above installation completed, the main GRUB directory is located at {{ic|/boot/grub/}}. Read [[/Tips and tricks#Alternative install method]] for how to specify an alternative location. Note that {{ic|grub-install}} also tries to [[#Create a GRUB entry in the firmware boot manager|create an entry in the firmware boot manager]], named {{ic|GRUB}} in the above example – this will, however, fail if your boot entries are full; use [[efibootmgr]] to remove unnecessary entries.<br />
<br />
Remember to [[#Generate the main configuration file]] after finalizing the configuration.<br />
<br />
{{Tip|If you use the option {{ic|--removable}} then GRUB will be installed to {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} (or {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} for the {{ic|i386-efi}} target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself similar to how you would using BIOS. If dual booting with Windows, be aware Windows usually places an EFI executable there, but its only purpose is to recreate the UEFI boot entry for Windows. If you are installing GRUB on a [[Mac]], you will have to use this option.}}<br />
<br />
{{Note|<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI, {{ic|--efi-directory}} replaces {{ic|--root-directory}} which is deprecated. <br />
* You might note the absence of a ''device_path'' option (e.g.: {{ic|/dev/sda}}) in the {{ic|grub-install}} command. In fact any ''device_path'' provided will be ignored by the GRUB UEFI install script. Indeed, UEFI bootloaders do not use a MBR bootcode or partition boot sector at all.<br />
}}<br />
<br />
See [[#UEFI|UEFI troubleshooting]] in case of problems. Additionally see [[/Tips and tricks#UEFI further reading]].<br />
<br />
== BIOS systems ==<br />
<br />
=== GUID Partition Table (GPT) specific instructions ===<br />
<br />
On a BIOS/[[GPT]] configuration, a [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note|<br />
* Before attempting this method keep in mind that not all systems will be able to support this partitioning scheme. Read more on [[Partitioning#GUID Partition Table]].<br />
* The BIOS boot partition is only needed by GRUB on a BIOS/GPT setup. On a BIOS/MBR setup, GRUB uses the post-MBR gap for the embedding the {{ic|core.img}}. On GPT, however, there is no guaranteed unused space before the first partition.<br />
* For [[UEFI]] systems this extra partition is not required, since no embedding of boot sectors takes place in that case. However, UEFI systems still require an [[EFI system partition]].<br />
}}<br />
<br />
Create a mebibyte partition ({{ic|1=+1M}} with ''fdisk'' or ''gdisk'') on the disk with no file system and with partition type GUID {{ic|21686148-6449-6E6F-744E-656564454649}}.<br />
<br />
* Select partition type {{ic|BIOS boot}} for [[fdisk]].<br />
* Select partition type code {{ic|ef02}} for [[gdisk]].<br />
* For [[parted]] set/activate the flag {{ic|bios_grub}} on the partition.<br />
<br />
This partition can be in any position order but has to be on the first 2 TiB of the disk. This partition needs to be created before GRUB installation. When the partition is ready, install the bootloader as per the instructions below.<br />
<br />
The space before the first partition can also be used as the BIOS boot partition though it will be out of GPT alignment specification. Since the partition will not be regularly accessed performance issues can be disregarded, though some disk utilities will display a warning about it. In ''fdisk'' or ''gdisk'' create a new partition starting at sector 34 and spanning to 2047 and set the type. To have the viewable partitions begin at the base consider adding this partition last.<br />
<br />
=== Master Boot Record (MBR) specific instructions ===<br />
<br />
Usually the post-MBR gap (after the 512 byte [[MBR]] region and before the start of the first partition) in many MBR partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{Bug|24103}}). It is advisable to use a partitioning tool that supports 1 MiB [[Partitioning#Partition alignment|partition alignment]] to obtain this space as well as to satisfy other non-512-byte-sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{Pkg|grub}} package. (It will replace {{AUR|grub-legacy}} if that is already installed.) Then do:<br />
<br />
# grub-install --target=i386-pc ''/dev/sdX''<br />
<br />
where {{ic|i386-pc}} is deliberately used regardless of your actual architecture, and {{ic|''/dev/sdX''}} is the '''disk''' ('''not a partition''') where GRUB is to be installed. For example {{ic|/dev/sda}} or {{ic|/dev/nvme0n1}}, or {{ic|/dev/mmcblk0}}. See [[Device file#Block device names]] for a description of the block device naming scheme.<br />
<br />
Now you must [[#Generate the main configuration file|generate the main configuration file]].<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
{{Tip|See [[/Tips and tricks#Alternative installation methods]] for other ways to install GRUB, such as to a USB stick.}}<br />
<br />
See {{man|8|grub-install}} and [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation GRUB Manual] for more details on the {{ic|grub-install}} command.<br />
<br />
== Configuration ==<br />
<br />
On an installed system, GRUB loads the {{ic|/boot/grub/grub.cfg}} configuration file each boot. You can follow [[#Generated grub.cfg]] for using a tool, or [[#Custom grub.cfg]] for a manual creation.<br />
<br />
=== Generated grub.cfg ===<br />
<br />
This section only covers editing the {{ic|/etc/default/grub}} configuration file. See [[/Tips and tricks]] for more information.<br />
<br />
{{Note|Remember to always [[#Generate the main configuration file|generate the main configuration file]] after making changes to {{ic|/etc/default/grub}} and/or files in {{ic|/etc/grub.d/}}.}}<br />
<br />
{{Warning|Update/reinstall the bootloader (see [[#UEFI systems]] or [[#BIOS systems]]) if a new GRUB version changes the syntax of the configuration file: mismatching configuration can result in an unbootable system.}}<br />
<br />
==== Generate the main configuration file ====<br />
<br />
After the installation, the main configuration file {{ic|/boot/grub/grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}.<br />
<br />
If you have not done additional configuration, the automatic generation will determine the root filesystem of the system to boot for the configuration file. For that to succeed it is important that the system is either booted or chrooted into.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* The default file path is {{ic|/boot/grub/grub.cfg}}, not {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a [[chroot]] or [[systemd-nspawn]] container, you might notice that it does not work: {{ic|grub-probe: error: failed to get canonical path of ''/dev/sdaX''}}. In this case, try using [[arch-chroot]] as described in the [https://bbs.archlinux.org/viewtopic.php?pid=1225067#p1225067 BBS post].<br />
* If you are installing GRUB in chroot environment using LVM and the {{ic|grub-mkconfig}} hangs indefinitely, see [[#Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds]].<br />
}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|/boot/grub/grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
By default the generation scripts automatically add menu entries for all installed Arch Linux [[kernel]]s to the generated configuration.<br />
<br />
{{Tip|<br />
* After installing or removing a [[kernel]], you just need to re-run the above ''grub-mkconfig'' command.<br />
* For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[/Tips and tricks#Multiple entries]].<br />
}}<br />
<br />
To automatically add entries for other installed operating systems, see [[#Detecting other operating systems]].<br />
<br />
You can add additional custom menu entries by editing {{ic|/etc/grub.d/40_custom}} and re-generating {{ic|/boot/grub/grub.cfg}}. Or you can create {{ic|/boot/grub/custom.cfg}} and add them there. Changes to {{ic|/boot/grub/custom.cfg}} do not require re-running ''grub-mkconfig'', since {{ic|/etc/grub.d/41_custom}} adds the necessary {{ic|source}} statement to the generated configuration file.<br />
<br />
{{Tip|{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/''nn''_custom}}, where {{ic|''nn''}} defines the precedence, indicating the order the script is executed. The order scripts are executed determine the placement in the GRUB boot menu. {{ic|''nn''}} should be greater than {{ic|06}} to ensure necessary scripts are executed first.}}<br />
<br />
See [[#Boot menu entry examples]] for custom menu entry examples.<br />
<br />
==== Detecting other operating systems ====<br />
<br />
To have ''grub-mkconfig'' search for other installed systems and automatically add them to the menu, [[install]] the {{Pkg|os-prober}} package and [[mount]] the partitions from which the other systems boot. Then re-run ''grub-mkconfig''. If you get the following output: {{ic|Warning: os-prober will not be executed to detect other bootable partitions}} then edit {{ic|/etc/default/grub}} and add/uncomment:<br />
GRUB_DISABLE_OS_PROBER=false<br />
Then try again.<br />
<br />
{{Note| <br />
* The exact mount point does not matter, ''os-prober'' reads the {{ic|mtab}} to identify places to search for bootable entries.<br />
* Remember to mount the partitions each time you run ''grub-mkconfig'' in order to include the other operating systems every time.<br />
}}<br />
<br />
{{Tip|You might also want GRUB to remember the last chosen boot entry, see [[/Tips and tricks#Recall previous entry]].}}<br />
<br />
===== Windows =====<br />
<br />
For Windows installed in UEFI mode, make sure the [[EFI system partition]] containing the Windows Boot Manager ({{ic|bootmgfw.efi}}) is mounted. Run {{ic|os-prober}} as root to detect and generate an entry for it.<br />
<br />
For Windows installed in BIOS mode, mount the Windows ''system partition'' (its [[Persistent block device naming#by-label|file system label]] should be {{ic|System Reserved}} or {{ic|SYSTEM}}). Run {{ic|os-prober}} as root to detect and generate an entry for it.<br />
<br />
{{Note|For Windows installed in BIOS mode:<br />
<br />
* NTFS partitions may not always be detected when mounted with the default Linux drivers. If GRUB is not detecting it, try installing [[NTFS-3G]] and remounting.<br />
{{Out of date|Since Windows 7, {{ic|bootmgr}} is placed in the [[Wikipedia:System partition and boot partition#Microsoft definition|system partition]] which is not encrypted.}}<br />
* Encrypted Windows partitions may need to be decrypted before mounting. For BitLocker, this can be done with [[cryptsetup]] or {{AUR|dislocker}}. This should be sufficient for {{Pkg|os-prober}} to add the correct entry.<br />
}}<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation.<br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|1=GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=''uuid-of-swap-partition'' quiet"}} where {{ic|''uuid-of-swap-partition''}} is the [[UUID]] of your swap partition to enable resume after [[hibernation]]. This would generate a recovery boot entry without the resume and without {{ic|quiet}} suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options.<br />
<br />
By default ''grub-mkconfig'' determines the [[UUID]] of the root filesystem for the configuration. To disable this, uncomment {{ic|1=GRUB_DISABLE_LINUX_UUID=true}}.<br />
<br />
For generating the GRUB recovery entry you have to ensure that {{ic|GRUB_DISABLE_RECOVERY}} is not set to {{ic|true}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
==== LVM ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|lvm}} module, specifying it in {{ic|GRUB_PRELOAD_MODULES}} is not required. Move warning to [[#Installation]] & [[#Installation_2]] or create a [[Help:Style#"Known issues" section|Known issues section]] and document it there.}}<br />
<br />
{{Warning|GRUB does not support thin-provisioned logical volumes.}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}} or {{ic|/}} root partition, make sure that the {{ic|lvm}} module is preloaded:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... lvm"<br />
}}<br />
<br />
==== RAID ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|mdraid09}} and/or {{ic|mdraid1x}} modules, specifying them in {{ic|GRUB_PRELOAD_MODULES}} is not required. Summarize the double grub-install in a note and move it to [[#Installation]]; move {{ic|set root}} stuff to [[#Custom grub.cfg]].}}<br />
<br />
GRUB provides convenient handling of [[RAID]] volumes. You need to load GRUB modules {{ic|mdraid09}} or {{ic|mdraid1x}} to allow you to address the volume natively:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... mdraid09 mdraid1x"<br />
}}<br />
<br />
For example, {{ic|/dev/md0}} becomes:<br />
<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on BIOS systems, simply run ''grub-install'' on both of the drives, such as:<br />
<br />
# grub-install --target=i386-pc --debug /dev/sda<br />
# grub-install --target=i386-pc --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
{{Note|GRUB supports booting from [[Btrfs]] RAID 0/1/10, but ''not'' RAID 5/6. You may use [[mdadm]] for RAID 5/6, which is supported by GRUB.}}<br />
<br />
==== Encrypted /boot ====<br />
<br />
GRUB also has special support for booting with an encrypted {{ic|/boot}}. This is done by unlocking a [[LUKS]] blockdevice in order to read its configuration and load any [[initramfs]] and [[kernel]] from it. This option tries to solve the issue of having an [[dm-crypt/Specialties#Securing the unencrypted_boot partition|unencrypted boot partition]].<br />
<br />
{{Tip|{{ic|/boot}} is '''not''' required to be kept in a separate partition; it may also stay under the system's root {{ic|/}} directory tree.}}<br />
<br />
{{Warning|GRUB 2.06 has limited support for LUKS2. See the [[#LUKS2]] section below for details.}}<br />
<br />
To enable this feature encrypt the partition with {{ic|/boot}} residing on it using [[LUKS]] as normal. Then add the following option to {{ic|/etc/default/grub}}:<br />
<br />
{{hc|/etc/default/grub|output=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
This option is used by grub-install to generate the grub {{ic|core.img}}.<br />
<br />
Make sure to [[#Installation|install grub]] after modifying this option or encrypting the partition.<br />
<br />
Without further changes you will be prompted twice for a passphrase: the first for GRUB to unlock the {{ic|/boot}} mount point in early boot, the second to unlock the root filesystem itself as implemented by the initramfs. You can use a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]] to avoid this.<br />
<br />
{{Warning|<br />
* If you want to [[#Generate the main configuration file|generate the main configuration file]], make sure that {{ic|/boot}} is mounted.<br />
* In order to perform system updates involving the {{ic|/boot}} mount point, ensure that the encrypted {{ic|/boot}} is unlocked and mounted before performing an update. With a separate {{ic|/boot}} partition, this may be accomplished automatically on boot by using [[crypttab]] with a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]].<br />
}}<br />
<br />
{{Note|<br />
* If you use a special keymap, a default GRUB installation will not know it. This is relevant for how to enter the passphrase to unlock the LUKS blockdevice. See [[/Tips and tricks#Manual configuration of core image for early boot]].<br />
* If you experience issues getting the prompt for a password to display (errors regarding cryptouuid, cryptodisk, or "device not found"), try reinstalling GRUB and appending {{ic|1=--modules="part_gpt part_msdos"}} to the end of your {{ic|grub-install}} command.<br />
}}<br />
<br />
{{Tip|1=You can use [https://bbs.archlinux.org/viewtopic.php?id=234607 pacman hooks] to automount your {{ic|/boot}} when upgrades need to access related files.}}<br />
<br />
===== LUKS2 =====<br />
<br />
GRUB 2.06 has limited support for LUKS2. See [https://savannah.gnu.org/bugs/?55093 GRUB bug #55093].<br />
<br />
{{Tip|1=You can use {{AUR|grub-improved-luks2-git}} that has been patched for LUKS2 support.}}<br />
<br />
* Argon2id (''cryptsetup'' default) and Argon2i PBKDFs are not supported ([https://savannah.gnu.org/bugs/?59409 GRUB bug #59409]), only PBKDF2 is.<br />
* {{ic|grub-install}} does not support creating a core image that could be used for unlocking LUKS2. See the comments below or on {{AUR|grub-git}} for a workaround.<br />
<br />
Use {{ic|grub-install}} as described in the [[#Installation]] section. However, the generated EFI binary does not support LUKS2 and needs to be replaced.<br />
<br />
Create {{ic|grub-pre.cfg}}, replace {{ic|/dev/nvme0n1p2}} accordingly. The output is the UUID of the encrypted partition without hyphens.<br />
<br />
{{bc|<br />
# replace ... by the output of: lsblk -no TYPE,UUID ''/dev/nvme0n1p2''<nowiki> | awk '$1=="part"{print $2}' | tr -d -<br />
set crypto_uuid=...<br />
cryptomount -u $crypto_uuid<br />
# Replace crypto0 by lvm/NameOfVolume if you use LVM<br />
set root=crypto0<br />
set prefix=($root)/boot/grub<br />
insmod normal<br />
normal<br />
</nowiki>}}<br />
<br />
Add {{ic|lvm}} if you use [[LVM]]. Replace {{ic|ext2}} by {{ic|btrfs}} if needed:<br />
<br />
$ grub-mkimage -p /boot/grub -O x86_64-efi -c grub-pre.cfg -o /tmp/grubx64.efi luks2 part_gpt cryptodisk gcry_rijndael pbkdf2 gcry_sha256 ext2<br />
<br />
Copy to ESP:<br />
<br />
# install -v /tmp/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
<br />
If you enter an invalid passphrase during boot and end up at the GRUB rescue shell, try {{ic|cryptomount -a}} to mount all (hopefully only one) encrypted partitions or use {{ic|cryptomount -u $crypto_uuid}} to mount a specific one. Then proceed with {{ic|insmod normal}} and {{ic|normal}} as usual.<br />
<br />
If you enter a correct passphrase, but an {{ic|Invalid passphrase}} error is immediately returned, make sure that the right cryptographic modules are specified. Use {{ic|cryptsetup luksDump ''/dev/nvme0n1p2''}} and check whether the hash function (SHA-256, SHA-512) matches the modules ({{ic|gcry_sha256}}, {{ic|gcry_sha512}}) installed and the PBKDF algorithm is pbkdf2. The hash and PBDKDF algorithms can be changed for existing keys by using {{ic|cryptsetup luksConvertKey --hash ''sha256'' --pbkdf pbkdf2 ''/dev/nvme0n1p2''}}. Under normal circumstances it should take a few seconds before the passphrase is processed.<br />
<br />
=== Custom grub.cfg ===<br />
<br />
{{Expansion|Add instructions on how to write a custom {{ic|/boot/grub/grub.cfg}}. See [[User:Eschwartz/Grub]] for a proposed draft.|section=Manually generate grub.cfg}}<br />
<br />
This section describes the manual creation of GRUB boot entries in {{ic|/boot/grub/grub.cfg}} instead of relying on ''grub-mkconfig''.<br />
<br />
A basic GRUB config file uses the following options:<br />
<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
==== Boot menu entry examples ====<br />
<br />
{{Tip|These boot entries can also be used when using a {{ic|/boot/grub/grub.cfg}} generated by ''grub-mkconfig''. Add them to {{ic|/etc/grub.d/40_custom}} and [[#Generate the main configuration file|re-generate the main configuration file]] or add them to {{ic|/boot/grub/custom.cfg}}.}}<br />
<br />
For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[/Tips and tricks#Multiple entries]].<br />
<br />
For [[Archiso]] and [https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] boot menu entries see [[Multiboot USB drive#Boot entries]].<br />
<br />
===== GRUB commands =====<br />
<br />
====== "Shutdown" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
}}<br />
<br />
====== "Restart" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}<br />
}}<br />
<br />
====== "UEFI Firmware Settings" menu entry ======<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
menuentry 'UEFI Firmware Settings' --id 'uefi-firmware' {<br />
fwsetup<br />
}<br />
fi<br />
}}<br />
<br />
===== EFI binaries =====<br />
<br />
When launched in UEFI mode, GRUB can chainload other EFI binaries.<br />
<br />
{{Tip|1=To show these menu entries only when GRUB is launched in UEFI mode, enclose them in the following {{ic|if}} statement:<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
''place UEFI-only menu entries here''<br />
fi<br />
}}<br />
<br />
}}<br />
<br />
====== UEFI Shell ======<br />
<br />
You can launch [[Unified Extensible Firmware Interface#UEFI Shell|UEFI Shell]] by placing it in the root of the [[EFI system partition]] and adding this menu entry:<br />
<br />
{{bc|1=<br />
menuentry "UEFI Shell" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /shellx64.efi<br />
chainloader /shellx64.efi<br />
}<br />
}}<br />
<br />
====== gdisk ======<br />
<br />
Download the [[gdisk#gdisk EFI application|gdisk EFI application]] and copy {{ic|gdisk_x64.efi}} to {{ic|''esp''/EFI/tools/}}.<br />
<br />
{{bc|1=<br />
menuentry "gdisk" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /EFI/tools/gdisk_x64.efi<br />
chainloader /EFI/tools/gdisk_x64.efi<br />
}<br />
}}<br />
<br />
====== Chainloading a unified kernel image ======<br />
<br />
If you have a [[unified kernel image]] generated from following [[Secure Boot]] or other means, you can add it to the boot menu. For example:<br />
<br />
{{bc|1=<br />
menuentry "Arch Linux" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --fs-uuid ''FILESYSTEM_UUID''<br />
chainloader /EFI/Linux/Arch-linux.efi<br />
}<br />
}}<br />
<br />
===== Dual-booting =====<br />
<br />
====== GNU/Linux ======<br />
<br />
Assuming that the other distribution is on partition {{ic|sda2}}:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
Alternatively let GRUB search for the right partition by UUID or file system label:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
# assuming that UUID is 763A-9CB6<br />
search --no-floppy --set=root --fs-uuid 763A-9CB6<br />
<br />
# search by label OTHER_LINUX (make sure that partition label is unambiguous)<br />
#search --no-floppy --set=root --label OTHER_LINUX<br />
<br />
linux /boot/vmlinuz (add other options here as required, for example: root=UUID=763A-9CB6)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
If the other distribution has already a valid {{ic|/boot}} folder with installed GRUB, {{ic|grub.cfg}}, kernel and initramfs, GRUB can be instructed to load these other {{ic|grub.cfg}} files on-the-fly during boot. For example, for {{ic|hd0}} and the fourth GPT partition:<br />
<br />
{{bc|1=<br />
menuentry "configfile hd0,gpt4" {<br />
insmod part_gpt<br />
insmod btrfs<br />
insmod ext2<br />
set root='hd0,gpt4'<br />
configfile /boot/grub/grub.cfg<br />
}<br />
}}<br />
<br />
When choosing this entry, GRUB loads the {{ic|grub.cfg}} file from the other volume and displays that menu. Any environment variable changes made by the commands in file will not be preserved after {{ic|configfile}} returns. Press {{ic|Esc}} to return to the first GRUB menu.<br />
<br />
====== Windows installed in UEFI/GPT mode ======<br />
<br />
This mode determines where the Windows bootloader resides and chain-loads it after GRUB when the menu entry is selected. The main task here is finding the EFI system partition and running the bootloader from it.<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the UEFI bitness. It will not work in BIOS installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] for more information.}}<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI/GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi<br />
}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands.<br />
<br />
The {{ic|$fs_uuid}} command determines the UUID of the EFI system partition:<br />
<br />
{{hc|1=# grub-probe --target=fs_uuid ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
1ce5-7f28<br />
}}<br />
<br />
Alternatively one can run {{ic|lsblk --fs}} and read the UUID of the EFI system partition from there.<br />
<br />
The {{ic|$hints_string}} command will determine the location of the EFI system partition, in this case harddrive 0:<br />
<br />
{{hc|1=# grub-probe --target=hints_string ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1<br />
}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|''esp''}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
====== Windows installed in BIOS/MBR mode ======<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and [https://www.gnu.org/software/grub/manual/grub.html#Chain_002dloading chainloading] of partition boot sector is no longer required to boot Windows in a BIOS/MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually {{ic|C:}}). The system partition's [[Persistent block device naming#by-label|filesystem label]] is {{ic|System Reserved}} or {{ic|SYSTEM}} and the partition is only about 100 to 549 MiB in size. See [[Wikipedia:System partition and boot partition]] for more information.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of {{ic|hd0,msdos1}}.<br />
<br />
{{Note|These menu entries will work only in BIOS boot mode. It will not work in UEFI installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] .}}<br />
<br />
In both examples {{ic|''XXXXXXXXXXXXXXXX''}} is the filesystem UUID which can be found with command {{ic|lsblk --fs}}.<br />
<br />
For Windows Vista/7/8/8.1/10:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1/10 BIOS/MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr<br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /bootmgr<br />
}<br />
fi<br />
}}<br />
<br />
For Windows XP:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr<br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /ntldr<br />
}<br />
fi<br />
}}<br />
<br />
{{Note|In some cases, GRUB may be installed without a clean Windows 8, in which case you cannot boot Windows without having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it by going to Windows Recovery Console ({{ic|cmd.exe}} from install disk) and executing:<br />
<br />
X:\> bootrec.exe /fixboot<br />
X:\> bootrec.exe /RebuildBcd<br />
<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.<br />
Or you can use Boot Repair function in the Troubleshooting menu - it will not wipe out GRUB but will fix most errors.<br />
Also you would better keep plugged in both the target hard drive and your bootable device '''ONLY'''. Windows usually fails to repair boot information if any other devices are connected.<br />
}}<br />
<br />
===== Using labels =====<br />
<br />
It is possible to use file system labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, [[Persistent block device naming#by-label|make sure your file system has a label]].<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub/}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
<br />
grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub><br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the start of a partitioned disk (MBR), at the start of a partition or a partitionless disk (VBR), or as an EFI binary in the case of UEFI.<br />
<br />
==== Chainloading a partition's VBR ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partition of the first hard disk,<br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk's MBR or a partitionless disk's VBR ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod fat<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
{{ic|insmod fat}} is used for loading the FAT file system module for accessing the Windows bootloader on the EFI system partition.<br />
{{ic|(hd0,gpt4)}} or {{ic|/dev/sda4}} is the EFI system partition in this example.<br />
The entry in the {{ic|chainloader}} line specifies the path of the ''.efi'' file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[#Using the rescue console]]<br />
<br />
=== Using the rescue console ===<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
<br />
grub rescue> set prefix=(hd''X'',''Y'')/boot/grub<br />
<br />
where {{ic|''X''}} is the physical drive number and {{ic|''Y''}} is the partition number.<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path (i.e. type {{ic|1=set prefix=(hd''X'',''Y'')/grub}}).}}<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
or simply<br />
<br />
grub rescue> insmod linux<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar.<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using UEFI), again change the lines accordingly:<br />
<br />
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}<br />
<br />
set root=(hd0,5)<br />
linux (hd''X'',''Y'')/vmlinuz-linux root=/dev/sda6<br />
initrd (hd''X'',''Y'')/initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== GRUB removal ==<br />
<br />
{{Expansion|Migrating from BIOS booting to UEFI is not the only case where GRUB could be removed. Section needs to either cover how to remove GRUB installed for UEFI booting or it should be removed altogether as too trivial.}}<br />
<br />
In general, in order to remove ''grub'', one has to do the installation steps in reverse order. Perhaps cleaning any left over at the end. However, before doing anything, one has to decide if, and how, the machine will boot after the removal. Assuming one removes ''grub'' because they would like to use another boot loader, a safe, though a bit difficult, method is to make sure the other boot loader is working before removing ''grub''.<br />
<br />
In any case, even when removing ''grub'' before installing another boot loader, for the UEFI case, run:<br />
<br />
$ efibootmgr<br />
<br />
And verify the other boot loader is listed in the {{ic|BootOrder}} line. If ''grub'' was not removed, the other boot loader should be listed before ''grub''. If ''grub'' is already removed, ''grub'' should not be mentioned in that line. But note this is only a necessary, but not sufficient, condition for the machine to boot with the other boot loader. Neither it is a sufficient condition for the full removal of ''grub''.<br />
<br />
For both UEFI and non UEFI machines, {{ic|grub-install}} was manually run as part of the installation of ''grub''. One of its jobs for the UEFI case was to run the equivalent of {{ic|efibootmgr --create}}. As part of ''grub'' removal, one has to remove the products of {{ic|grub-install}}. The opposite of {{ic|efibootmgr --create}} is {{ic|efibootmgr --delete-bootnum}}, or an equivalent program. One way to obtain the number of the boot entry for the {{ic|efibootmgr --delete-bootnum}} command is from the output of {{ic|efibootmgr}} (with no arguments).<br />
<br />
{{ic|grub-install}} creates the {{ic|/boot/grub}} directory that needs to be removed manually. Though some users will want to keep it, should they want to install ''grub'' again.<br />
<br />
After migrating to GPT/UEFI one may want to remove the [[Partitioning#Master Boot Record (bootstrap code)|MBR boot code]] [[dd#Remove bootloader|using dd]]:<br />
<br />
# dd if=/dev/zero of=/dev/sd''X'' bs=440 count=1<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unsupported file systems ===<br />
<br />
In case that GRUB does not support the root file system, an alternative {{ic|/boot}} partition with a supported file system must be created. In some cases, the development version of GRUB {{aur|grub-git}} may have native support for the file system.<br />
<br />
If GRUB is used with an unsupported file system it is not able to extract the [[UUID]] of your drive so it uses classic non-persistent {{ic|/dev/''sdXx''}} names instead. In this case you might have to manually edit {{ic|/boot/grub/grub.cfg}} and replace {{ic|1=root=/dev/''sdXx''}} with {{ic|1=root=UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}}. You can use the {{ic|blkid}} command to get the UUID of your device, see [[Persistent block device naming]].<br />
<br />
While GRUB supports [[F2FS]] since version 2.0.4, it cannot correctly read its boot files from an F2FS partition that was created with the {{ic|extra_attr}} flag enabled.<br />
<br />
=== Enable debug messages ===<br />
<br />
{{Note|This change is overwritten when [[#Generate the main configuration file]].}}<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== UEFI ===<br />
<br />
==== Common installation errors ====<br />
<br />
* If you have a problem when running ''grub-install'' with ''sysfs'' or ''procfs'' and it says you must run {{ic|modprobe efivarfs}}, try [[Unified Extensible Firmware Interface#Mount efivarfs]].<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* If after running grub-install you are told your partition does not look like an EFI partition then the partition is most likely not {{ic|Fat32}}.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
As another example of creating a GRUB entry in the firmware boot manager, consider {{ic|efibootmgr -c}}. This assumes that /dev/sda1 is the EFI System Partition, and is mounted at /boot/efi. Which are the default behavior of {{ic|efibootmgr}}. It creates a new boot option, called "Linux", and puts it at the top of the boot order list. Options may be passed to modify the default behavior. The default OS Loader is \EFI\arch\grub.efi.<br />
<br />
==== Drop to rescue shell ====<br />
<br />
If GRUB loads but drops into the rescue shell with no errors, it can be due to one of these two reasons:<br />
<br />
* It may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing,<br />
* It also happens if the boot partition, which is hardcoded into the {{ic|grubx64.efi}} file, has changed.<br />
<br />
==== GRUB UEFI not loaded ====<br />
<br />
An example of a working UEFI:<br />
<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EFI\GRUB\grubx64.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\shellx64.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grubx64.efi)<br />
<br />
==== Default/fallback boot path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to install GRUB at the default/fallback boot path:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' '''--removable'''<br />
<br />
Alternatively you can move an already installed GRUB EFI executable to the default/fallback path:<br />
<br />
# mv ''esp''/EFI/grub ''esp''/EFI/BOOT<br />
# mv ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/BOOTX64.EFI<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions may have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}}.<br />
<br />
=== Warning when installing in chroot ===<br />
<br />
When installing GRUB on a LVM system in a chroot environment (e.g. during system installation), you may receive warnings like<br />
<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
<br />
or<br />
<br />
WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.<br />
<br />
This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
<br />
=== GRUB loads slowly ===<br />
<br />
GRUB can take a long time to load when disk space is low. Check if you have sufficient free disk space on your {{ic|/boot}} or {{ic|/}} partition when you are having problems.<br />
<br />
=== error: unknown filesystem ===<br />
<br />
GRUB may output {{ic|error: unknown filesystem}} and refuse to boot for a few reasons. If you are certain that all [[UUID]]s are correct and all filesystems are valid and supported, it may be because your [[#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] is located outside the first 2 TiB of the drive [https://bbs.archlinux.org/viewtopic.php?id=195948]. Use a partitioning tool of your choice to ensure this partition is located fully within the first 2 TiB, then reinstall and reconfigure GRUB.<br />
<br />
This error might also be caused by an [[ext4]] filesystem having unsupported features set:<br />
* {{ic|large_dir}} - unsupported.<br />
* {{ic|metadata_csum_seed}} - will be supported in GRUB 2.11 ([https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 commit]).<br />
<br />
{{Warning|Make sure to check GRUB support for new [[file system]] features before you enable them on your {{ic|/boot}} file system.}}<br />
<br />
=== grub-reboot not resetting ===<br />
<br />
GRUB seems to be unable to write to root BTRFS partitions [https://bbs.archlinux.org/viewtopic.php?id=166131]. If you use grub-reboot to boot into another entry it will therefore be unable to update its on-disk environment. Either run grub-reboot from the other entry (for example when switching between various distributions) or consider a different file system. You can reset a "sticky" entry by executing {{ic|grub-editenv create}} and setting {{ic|1=GRUB_DEFAULT=0}} in your {{ic|/etc/default/grub}} (do not forget {{ic|grub-mkconfig -o /boot/grub/grub.cfg}}).<br />
<br />
=== Old BTRFS prevents installation ===<br />
<br />
If a drive is formatted with BTRFS without creating a partition table (eg. /dev/sdx), then later has partition table written to, there are parts of the BTRFS format that persist. Most utilities and OS's do not see this, but GRUB will refuse to install, even with --force<br />
<br />
# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..<br />
# grub-install: error: filesystem `btrfs' does not support blocklists.<br />
<br />
You can zero the drive, but the easy solution that leaves your data alone is to erase the BTRFS superblock with {{ic|wipefs -o 0x10040 /dev/sdx}}<br />
<br />
=== Windows 8/10 not found ===<br />
<br />
A setting in Windows 8/10 called "Hiberboot", "Hybrid Boot" or "Fast Boot" can prevent the Windows partition from being mounted, so {{ic|grub-mkconfig}} will not find a Windows install. Disabling Hiberboot in Windows will allow it to be added to the GRUB menu.<br />
<br />
=== VirtualBox EFI mode ===<br />
<br />
For VirtualBox < 6.1, install GRUB to the [[#Default/fallback boot path|default/fallback boot path]].<br />
<br />
See also [[VirtualBox#Installation in EFI mode on VirtualBox < 6.1]].<br />
<br />
=== Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds ===<br />
<br />
If grub-mkconfig hangs and gives error: {{ic|WARNING: Device /dev/''xxx'' not initialized in udev database even after waiting 10000000 microseconds}}.<br />
<br />
You may need to provide {{ic|/run/lvm/}} access to the chroot environment using:<br />
<br />
# mkdir /mnt/hostlvm<br />
# mount --bind /run/lvm /mnt/hostlvm<br />
# arch-chroot /mnt<br />
# ln -s /hostlvm /run/lvm<br />
<br />
See {{Bug|61040}} and [https://bbs.archlinux.org/viewtopic.php?pid=1820949#p1820949 workaround].<br />
<br />
=== GRUB rescue and encrypted /boot ===<br />
<br />
When using an [[#Encrypted /boot|encrypted /boot]], and you fail to input a correct password, you will be dropped in grub-rescue prompt.<br />
<br />
This grub-rescue prompt has limited capabilities. Use the following commands to complete the boot:<br />
{{bc|<br />
grub rescue> cryptomount <partition><br />
grub rescue> insmod normal<br />
grub rescue> normal<br />
}}<br />
<br />
See [https://blog.stigok.com/2017/12/29/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html this blog post] for a better description.<br />
<br />
=== GRUB is installed but the menu is not shown at boot ===<br />
<br />
Check {{ic|/etc/default/grub}} if {{ic|GRUB_TIMEOUT}} is set to {{ic|0}}, in which case set it to a positive number: it sets the number of seconds before the default GRUB entry is loaded. Also check if {{ic|GRUB_TIMEOUT_STYLE}} is set to {{ic|hidden}} and set it to {{ic|menu}}, so that the menu will be shown by default. Then [[#Generate the main configuration file|regenerate the main configuration file]] and reboot to check if it worked.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:GNU GRUB]]<br />
* [https://www.gnu.org/software/grub/manual/grub.html Official GRUB Manual]<br />
* [https://help.ubuntu.com/community/Grub2 Ubuntu wiki page for GRUB]<br />
* [https://help.ubuntu.com/community/UEFIBooting GRUB wiki page describing steps to compile for UEFI systems]<br />
* [[Wikipedia:BIOS Boot partition]]<br />
* [https://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme How to configure GRUB]<br />
* [https://archived.forum.manjaro.org/t/detecting-efi-files-and-booting-them-from-grub/38083 Detecting efi files and booting them from grub]</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=GRUB&diff=747748GRUB2022-09-22T13:51:18Z<p>DasMenschy: Add warning that the instructions with "insmod" on this page are outdated and not working if Secure Boot is enabled.</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[Category:GNU]]<br />
[[de:GRUB]]<br />
[[es:GRUB]]<br />
[[fa:گراب]]<br />
[[ja:GRUB]]<br />
[[pt:GRUB]]<br />
[[ru:GRUB]]<br />
[[zh-hans:GRUB]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|/EFI examples}}<br />
{{Related|/Tips and tricks}}<br />
{{Related|Multiboot USB drive}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] (GRand Unified Bootloader) is a [[boot loader]]. The current GRUB is also referred to as '''GRUB 2'''. The original GRUB, or [[GRUB Legacy]], corresponds to versions 0.9x. This page exclusively describes GRUB 2.<br />
<br />
{{Note|In the entire article {{ic|''esp''}} denotes the mountpoint of the [[EFI system partition]] aka ESP.}}<br />
<br />
== UEFI systems ==<br />
<br />
{{Note|<br />
* It is recommended to read and understand the [[Unified Extensible Firmware Interface]], [[Partitioning#GUID Partition Table]] and [[Arch boot process#Under UEFI]] pages.<br />
* When installing to use UEFI it is important to boot the installation media in UEFI mode, otherwise ''efibootmgr'' will not be able to add the GRUB UEFI boot entry. Installing to the [[#Default/fallback boot path|fallback boot path]] will still work even in BIOS mode since it does not touch the NVRAM.<br />
* To boot from a disk using UEFI, an EFI system partition is required. Follow [[EFI system partition#Check for an existing partition]] to find out if you have one already, otherwise you need to create it.<br />
}}<br />
{{Warning|This whole article assumes that inserting additional GRUB2 modules via {{ic|insmod}} is possible. This is not the case however with newer GRUB2 versions on UEFI systems where Secure Boot is enabled - Secure Boot should block sideloading any arbitrary code, which also means GRUB2 modules. If Secure Boot is enabled, {{ic|insmod ...}} will most likely fail and throw out a security violation. If you want to use any additional GRUB module that is not included in the standard GRUB EFI file {{ic|grubx64.efi}} on systems where Secure Boot is enabled, you have to re-generate the GRUB EFI {{ic|grubx64.efi}} with {{ic|grub-mkstandalone}} with the additional GRUB modules included.}}<br />
<br />
=== Installation ===<br />
<br />
{{Note|<br />
* UEFI firmwares are not implemented consistently across manufacturers. The procedure described below is intended to work on a wide range of UEFI systems but those experiencing problems despite applying this method are encouraged to share detailed information, and if possible the workarounds found, for their hardware-specific case. A [[/EFI examples]] article has been provided for such cases.<br />
* The section assumes you are installing GRUB for x86_64 systems. For IA32 (32-bit) UEFI systems (not to be confused with 32-bit CPUs), replace {{ic|x86_64-efi}} with {{ic|i386-efi}} where appropriate.<br />
* See [[Secure Boot]] for instructions on implementing it. <br />
}}<br />
<br />
First, [[install]] the packages {{Pkg|grub}} and {{Pkg|efibootmgr}}: ''GRUB'' is the bootloader while ''efibootmgr'' is used by the GRUB installation script to write boot entries to NVRAM. <br />
<br />
Then follow the below steps to install GRUB to your disk:<br />
<br />
# [[EFI system partition#Mount the partition|Mount the EFI system partition]] and in the remainder of this section, substitute {{ic|''esp''}} with its mount point.<br />
# Choose a bootloader identifier, here named {{ic|GRUB}}. A directory of that name will be created in {{ic|''esp''/EFI/}} to store the EFI binary and this is the name that will appear in the UEFI boot menu to identify the GRUB boot entry.<br />
# Execute the following command to install the GRUB EFI application {{ic|grubx64.efi}} to {{ic|''esp''/EFI/GRUB/}} and install its modules to {{ic|/boot/grub/x86_64-efi/}}. {{Note|Make sure to install the packages and run the {{ic|grub-install}} command from the system in which GRUB will be installed as the boot loader. That means if you are booting from the live installation environment, you need to be inside the chroot when running {{ic|grub-install}}. If for some reason it is necessary to run {{ic|grub-install}} from outside of the installed system, append the {{ic|1=--boot-directory=}} option with the path to the mounted {{ic|/boot}} directory, e.g {{ic|1=--boot-directory=/mnt/boot}}.}} {{bc|1=# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB}}<br />
<br />
After the above installation completed, the main GRUB directory is located at {{ic|/boot/grub/}}. Read [[/Tips and tricks#Alternative install method]] for how to specify an alternative location. Note that {{ic|grub-install}} also tries to [[#Create a GRUB entry in the firmware boot manager|create an entry in the firmware boot manager]], named {{ic|GRUB}} in the above example – this will, however, fail if your boot entries are full; use [[efibootmgr]] to remove unnecessary entries.<br />
<br />
Remember to [[#Generate the main configuration file]] after finalizing the configuration.<br />
<br />
{{Tip|If you use the option {{ic|--removable}} then GRUB will be installed to {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} (or {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} for the {{ic|i386-efi}} target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself similar to how you would using BIOS. If dual booting with Windows, be aware Windows usually places an EFI executable there, but its only purpose is to recreate the UEFI boot entry for Windows. If you are installing GRUB on a [[Mac]], you will have to use this option.}}<br />
<br />
{{Note|<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI, {{ic|--efi-directory}} replaces {{ic|--root-directory}} which is deprecated. <br />
* You might note the absence of a ''device_path'' option (e.g.: {{ic|/dev/sda}}) in the {{ic|grub-install}} command. In fact any ''device_path'' provided will be ignored by the GRUB UEFI install script. Indeed, UEFI bootloaders do not use a MBR bootcode or partition boot sector at all.<br />
}}<br />
<br />
See [[#UEFI|UEFI troubleshooting]] in case of problems. Additionally see [[/Tips and tricks#UEFI further reading]].<br />
<br />
== BIOS systems ==<br />
<br />
=== GUID Partition Table (GPT) specific instructions ===<br />
<br />
On a BIOS/[[GPT]] configuration, a [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note|<br />
* Before attempting this method keep in mind that not all systems will be able to support this partitioning scheme. Read more on [[Partitioning#GUID Partition Table]].<br />
* The BIOS boot partition is only needed by GRUB on a BIOS/GPT setup. On a BIOS/MBR setup, GRUB uses the post-MBR gap for the embedding the {{ic|core.img}}. On GPT, however, there is no guaranteed unused space before the first partition.<br />
* For [[UEFI]] systems this extra partition is not required, since no embedding of boot sectors takes place in that case. However, UEFI systems still require an [[EFI system partition]].<br />
}}<br />
<br />
Create a mebibyte partition ({{ic|1=+1M}} with ''fdisk'' or ''gdisk'') on the disk with no file system and with partition type GUID {{ic|21686148-6449-6E6F-744E-656564454649}}.<br />
<br />
* Select partition type {{ic|BIOS boot}} for [[fdisk]].<br />
* Select partition type code {{ic|ef02}} for [[gdisk]].<br />
* For [[parted]] set/activate the flag {{ic|bios_grub}} on the partition.<br />
<br />
This partition can be in any position order but has to be on the first 2 TiB of the disk. This partition needs to be created before GRUB installation. When the partition is ready, install the bootloader as per the instructions below.<br />
<br />
The space before the first partition can also be used as the BIOS boot partition though it will be out of GPT alignment specification. Since the partition will not be regularly accessed performance issues can be disregarded, though some disk utilities will display a warning about it. In ''fdisk'' or ''gdisk'' create a new partition starting at sector 34 and spanning to 2047 and set the type. To have the viewable partitions begin at the base consider adding this partition last.<br />
<br />
=== Master Boot Record (MBR) specific instructions ===<br />
<br />
Usually the post-MBR gap (after the 512 byte [[MBR]] region and before the start of the first partition) in many MBR partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{Bug|24103}}). It is advisable to use a partitioning tool that supports 1 MiB [[Partitioning#Partition alignment|partition alignment]] to obtain this space as well as to satisfy other non-512-byte-sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{Pkg|grub}} package. (It will replace {{AUR|grub-legacy}} if that is already installed.) Then do:<br />
<br />
# grub-install --target=i386-pc ''/dev/sdX''<br />
<br />
where {{ic|i386-pc}} is deliberately used regardless of your actual architecture, and {{ic|''/dev/sdX''}} is the '''disk''' ('''not a partition''') where GRUB is to be installed. For example {{ic|/dev/sda}} or {{ic|/dev/nvme0n1}}, or {{ic|/dev/mmcblk0}}. See [[Device file#Block device names]] for a description of the block device naming scheme.<br />
<br />
Now you must [[#Generate the main configuration file|generate the main configuration file]].<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
{{Tip|See [[/Tips and tricks#Alternative installation methods]] for other ways to install GRUB, such as to a USB stick.}}<br />
<br />
See {{man|8|grub-install}} and [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation GRUB Manual] for more details on the {{ic|grub-install}} command.<br />
<br />
== Configuration ==<br />
<br />
On an installed system, GRUB loads the {{ic|/boot/grub/grub.cfg}} configuration file each boot. You can follow [[#Generated grub.cfg]] for using a tool, or [[#Custom grub.cfg]] for a manual creation.<br />
<br />
=== Generated grub.cfg ===<br />
<br />
This section only covers editing the {{ic|/etc/default/grub}} configuration file. See [[/Tips and tricks]] for more information.<br />
<br />
{{Note|Remember to always [[#Generate the main configuration file|generate the main configuration file]] after making changes to {{ic|/etc/default/grub}} and/or files in {{ic|/etc/grub.d/}}.}}<br />
<br />
{{Warning|Update/reinstall the bootloader (see [[#UEFI systems]] or [[#BIOS systems]]) if a new GRUB version changes the syntax of the configuration file: mismatching configuration can result in an unbootable system.}}<br />
<br />
==== Generate the main configuration file ====<br />
<br />
After the installation, the main configuration file {{ic|/boot/grub/grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}.<br />
<br />
If you have not done additional configuration, the automatic generation will determine the root filesystem of the system to boot for the configuration file. For that to succeed it is important that the system is either booted or chrooted into.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* The default file path is {{ic|/boot/grub/grub.cfg}}, not {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a [[chroot]] or [[systemd-nspawn]] container, you might notice that it does not work: {{ic|grub-probe: error: failed to get canonical path of ''/dev/sdaX''}}. In this case, try using [[arch-chroot]] as described in the [https://bbs.archlinux.org/viewtopic.php?pid=1225067#p1225067 BBS post].<br />
* If you are installing GRUB in chroot environment using LVM and the {{ic|grub-mkconfig}} hangs indefinitely, see [[#Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds]].<br />
}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|/boot/grub/grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
By default the generation scripts automatically add menu entries for all installed Arch Linux [[kernel]]s to the generated configuration.<br />
<br />
{{Tip|<br />
* After installing or removing a [[kernel]], you just need to re-run the above ''grub-mkconfig'' command.<br />
* For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[/Tips and tricks#Multiple entries]].<br />
}}<br />
<br />
To automatically add entries for other installed operating systems, see [[#Detecting other operating systems]].<br />
<br />
You can add additional custom menu entries by editing {{ic|/etc/grub.d/40_custom}} and re-generating {{ic|/boot/grub/grub.cfg}}. Or you can create {{ic|/boot/grub/custom.cfg}} and add them there. Changes to {{ic|/boot/grub/custom.cfg}} do not require re-running ''grub-mkconfig'', since {{ic|/etc/grub.d/41_custom}} adds the necessary {{ic|source}} statement to the generated configuration file.<br />
<br />
{{Tip|{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/''nn''_custom}}, where {{ic|''nn''}} defines the precedence, indicating the order the script is executed. The order scripts are executed determine the placement in the GRUB boot menu. {{ic|''nn''}} should be greater than {{ic|06}} to ensure necessary scripts are executed first.}}<br />
<br />
See [[#Boot menu entry examples]] for custom menu entry examples.<br />
<br />
==== Detecting other operating systems ====<br />
<br />
To have ''grub-mkconfig'' search for other installed systems and automatically add them to the menu, [[install]] the {{Pkg|os-prober}} package and [[mount]] the partitions from which the other systems boot. Then re-run ''grub-mkconfig''. If you get the following output: {{ic|Warning: os-prober will not be executed to detect other bootable partitions}} then edit {{ic|/etc/default/grub}} and add/uncomment:<br />
GRUB_DISABLE_OS_PROBER=false<br />
Then try again.<br />
<br />
{{Note| <br />
* The exact mount point does not matter, ''os-prober'' reads the {{ic|mtab}} to identify places to search for bootable entries.<br />
* Remember to mount the partitions each time you run ''grub-mkconfig'' in order to include the other operating systems every time.<br />
}}<br />
<br />
{{Tip|You might also want GRUB to remember the last chosen boot entry, see [[/Tips and tricks#Recall previous entry]].}}<br />
<br />
===== Windows =====<br />
<br />
For Windows installed in UEFI mode, make sure the [[EFI system partition]] containing the Windows Boot Manager ({{ic|bootmgfw.efi}}) is mounted. Run {{ic|os-prober}} as root to detect and generate an entry for it.<br />
<br />
For Windows installed in BIOS mode, mount the Windows ''system partition'' (its [[Persistent block device naming#by-label|file system label]] should be {{ic|System Reserved}} or {{ic|SYSTEM}}). Run {{ic|os-prober}} as root to detect and generate an entry for it.<br />
<br />
{{Note|For Windows installed in BIOS mode:<br />
<br />
* NTFS partitions may not always be detected when mounted with the default Linux drivers. If GRUB is not detecting it, try installing [[NTFS-3G]] and remounting.<br />
{{Out of date|Since Windows 7, {{ic|bootmgr}} is placed in the [[Wikipedia:System partition and boot partition#Microsoft definition|system partition]] which is not encrypted.}}<br />
* Encrypted Windows partitions may need to be decrypted before mounting. For BitLocker, this can be done with [[cryptsetup]] or {{AUR|dislocker}}. This should be sufficient for {{Pkg|os-prober}} to add the correct entry.<br />
}}<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation.<br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|1=GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=''uuid-of-swap-partition'' quiet"}} where {{ic|''uuid-of-swap-partition''}} is the [[UUID]] of your swap partition to enable resume after [[hibernation]]. This would generate a recovery boot entry without the resume and without {{ic|quiet}} suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options.<br />
<br />
By default ''grub-mkconfig'' determines the [[UUID]] of the root filesystem for the configuration. To disable this, uncomment {{ic|1=GRUB_DISABLE_LINUX_UUID=true}}.<br />
<br />
For generating the GRUB recovery entry you have to ensure that {{ic|GRUB_DISABLE_RECOVERY}} is not set to {{ic|true}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
==== LVM ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|lvm}} module, specifying it in {{ic|GRUB_PRELOAD_MODULES}} is not required. Move warning to [[#Installation]] & [[#Installation_2]] or create a [[Help:Style#"Known issues" section|Known issues section]] and document it there.}}<br />
<br />
{{Warning|GRUB does not support thin-provisioned logical volumes.}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}} or {{ic|/}} root partition, make sure that the {{ic|lvm}} module is preloaded:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... lvm"<br />
}}<br />
<br />
==== RAID ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|mdraid09}} and/or {{ic|mdraid1x}} modules, specifying them in {{ic|GRUB_PRELOAD_MODULES}} is not required. Summarize the double grub-install in a note and move it to [[#Installation]]; move {{ic|set root}} stuff to [[#Custom grub.cfg]].}}<br />
<br />
GRUB provides convenient handling of [[RAID]] volumes. You need to load GRUB modules {{ic|mdraid09}} or {{ic|mdraid1x}} to allow you to address the volume natively:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... mdraid09 mdraid1x"<br />
}}<br />
<br />
For example, {{ic|/dev/md0}} becomes:<br />
<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on BIOS systems, simply run ''grub-install'' on both of the drives, such as:<br />
<br />
# grub-install --target=i386-pc --debug /dev/sda<br />
# grub-install --target=i386-pc --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
{{Note|GRUB supports booting from [[Btrfs]] RAID 0/1/10, but ''not'' RAID 5/6. You may use [[mdadm]] for RAID 5/6, which is supported by GRUB.}}<br />
<br />
==== Encrypted /boot ====<br />
<br />
GRUB also has special support for booting with an encrypted {{ic|/boot}}. This is done by unlocking a [[LUKS]] blockdevice in order to read its configuration and load any [[initramfs]] and [[kernel]] from it. This option tries to solve the issue of having an [[dm-crypt/Specialties#Securing the unencrypted_boot partition|unencrypted boot partition]].<br />
<br />
{{Tip|{{ic|/boot}} is '''not''' required to be kept in a separate partition; it may also stay under the system's root {{ic|/}} directory tree.}}<br />
<br />
{{Warning|GRUB 2.06 has limited support for LUKS2. See the [[#LUKS2]] section below for details.}}<br />
<br />
To enable this feature encrypt the partition with {{ic|/boot}} residing on it using [[LUKS]] as normal. Then add the following option to {{ic|/etc/default/grub}}:<br />
<br />
{{hc|/etc/default/grub|output=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
This option is used by grub-install to generate the grub {{ic|core.img}}.<br />
<br />
Make sure to [[#Installation|install grub]] after modifying this option or encrypting the partition.<br />
<br />
Without further changes you will be prompted twice for a passphrase: the first for GRUB to unlock the {{ic|/boot}} mount point in early boot, the second to unlock the root filesystem itself as implemented by the initramfs. You can use a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]] to avoid this.<br />
<br />
{{Warning|<br />
* If you want to [[#Generate the main configuration file|generate the main configuration file]], make sure that {{ic|/boot}} is mounted.<br />
* In order to perform system updates involving the {{ic|/boot}} mount point, ensure that the encrypted {{ic|/boot}} is unlocked and mounted before performing an update. With a separate {{ic|/boot}} partition, this may be accomplished automatically on boot by using [[crypttab]] with a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]].<br />
}}<br />
<br />
{{Note|<br />
* If you use a special keymap, a default GRUB installation will not know it. This is relevant for how to enter the passphrase to unlock the LUKS blockdevice. See [[/Tips and tricks#Manual configuration of core image for early boot]].<br />
* If you experience issues getting the prompt for a password to display (errors regarding cryptouuid, cryptodisk, or "device not found"), try reinstalling GRUB and appending {{ic|1=--modules="part_gpt part_msdos"}} to the end of your {{ic|grub-install}} command.<br />
}}<br />
<br />
{{Tip|1=You can use [https://bbs.archlinux.org/viewtopic.php?id=234607 pacman hooks] to automount your {{ic|/boot}} when upgrades need to access related files.}}<br />
<br />
===== LUKS2 =====<br />
<br />
GRUB 2.06 has limited support for LUKS2. See [https://savannah.gnu.org/bugs/?55093 GRUB bug #55093].<br />
<br />
{{Tip|1=You can use {{AUR|grub-improved-luks2-git}} that has been patched for LUKS2 support.}}<br />
<br />
* Argon2id (''cryptsetup'' default) and Argon2i PBKDFs are not supported ([https://savannah.gnu.org/bugs/?59409 GRUB bug #59409]), only PBKDF2 is.<br />
* {{ic|grub-install}} does not support creating a core image that could be used for unlocking LUKS2. See the comments below or on {{AUR|grub-git}} for a workaround.<br />
<br />
Use {{ic|grub-install}} as described in the [[#Installation]] section. However, the generated EFI binary does not support LUKS2 and needs to be replaced.<br />
<br />
Create {{ic|grub-pre.cfg}}, replace {{ic|/dev/nvme0n1p2}} accordingly. The output is the UUID of the encrypted partition without hyphens.<br />
<br />
{{bc|<br />
# replace ... by the output of: lsblk -no TYPE,UUID ''/dev/nvme0n1p2''<nowiki> | awk '$1=="part"{print $2}' | tr -d -<br />
set crypto_uuid=...<br />
cryptomount -u $crypto_uuid<br />
# Replace crypto0 by lvm/NameOfVolume if you use LVM<br />
set root=crypto0<br />
set prefix=($root)/boot/grub<br />
insmod normal<br />
normal<br />
</nowiki>}}<br />
<br />
Add {{ic|lvm}} if you use [[LVM]]. Replace {{ic|ext2}} by {{ic|btrfs}} if needed:<br />
<br />
$ grub-mkimage -p /boot/grub -O x86_64-efi -c grub-pre.cfg -o /tmp/grubx64.efi luks2 part_gpt cryptodisk gcry_rijndael pbkdf2 gcry_sha256 ext2<br />
<br />
Copy to ESP:<br />
<br />
# install -v /tmp/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
<br />
If you enter an invalid passphrase during boot and end up at the GRUB rescue shell, try {{ic|cryptomount -a}} to mount all (hopefully only one) encrypted partitions or use {{ic|cryptomount -u $crypto_uuid}} to mount a specific one. Then proceed with {{ic|insmod normal}} and {{ic|normal}} as usual.<br />
<br />
If you enter a correct passphrase, but an {{ic|Invalid passphrase}} error is immediately returned, make sure that the right cryptographic modules are specified. Use {{ic|cryptsetup luksDump ''/dev/nvme0n1p2''}} and check whether the hash function (SHA-256, SHA-512) matches the modules ({{ic|gcry_sha256}}, {{ic|gcry_sha512}}) installed and the PBKDF algorithm is pbkdf2. The hash and PBDKDF algorithms can be changed for existing keys by using {{ic|cryptsetup luksConvertKey --hash ''sha256'' --pbkdf pbkdf2 ''/dev/nvme0n1p2''}}. Under normal circumstances it should take a few seconds before the passphrase is processed.<br />
<br />
=== Custom grub.cfg ===<br />
<br />
{{Expansion|Add instructions on how to write a custom {{ic|/boot/grub/grub.cfg}}. See [[User:Eschwartz/Grub]] for a proposed draft.|section=Manually generate grub.cfg}}<br />
<br />
This section describes the manual creation of GRUB boot entries in {{ic|/boot/grub/grub.cfg}} instead of relying on ''grub-mkconfig''.<br />
<br />
A basic GRUB config file uses the following options:<br />
<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
==== Boot menu entry examples ====<br />
<br />
{{Tip|These boot entries can also be used when using a {{ic|/boot/grub/grub.cfg}} generated by ''grub-mkconfig''. Add them to {{ic|/etc/grub.d/40_custom}} and [[#Generate the main configuration file|re-generate the main configuration file]] or add them to {{ic|/boot/grub/custom.cfg}}.}}<br />
<br />
For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[/Tips and tricks#Multiple entries]].<br />
<br />
For [[Archiso]] and [https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] boot menu entries see [[Multiboot USB drive#Boot entries]].<br />
<br />
===== GRUB commands =====<br />
<br />
====== "Shutdown" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
}}<br />
<br />
====== "Restart" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}<br />
}}<br />
<br />
====== "UEFI Firmware Settings" menu entry ======<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
menuentry 'UEFI Firmware Settings' --id 'uefi-firmware' {<br />
fwsetup<br />
}<br />
fi<br />
}}<br />
<br />
===== EFI binaries =====<br />
<br />
When launched in UEFI mode, GRUB can chainload other EFI binaries.<br />
<br />
{{Tip|1=To show these menu entries only when GRUB is launched in UEFI mode, enclose them in the following {{ic|if}} statement:<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
''place UEFI-only menu entries here''<br />
fi<br />
}}<br />
<br />
}}<br />
<br />
====== UEFI Shell ======<br />
<br />
You can launch [[Unified Extensible Firmware Interface#UEFI Shell|UEFI Shell]] by placing it in the root of the [[EFI system partition]] and adding this menu entry:<br />
<br />
{{bc|1=<br />
menuentry "UEFI Shell" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /shellx64.efi<br />
chainloader /shellx64.efi<br />
}<br />
}}<br />
<br />
====== gdisk ======<br />
<br />
Download the [[gdisk#gdisk EFI application|gdisk EFI application]] and copy {{ic|gdisk_x64.efi}} to {{ic|''esp''/EFI/tools/}}.<br />
<br />
{{bc|1=<br />
menuentry "gdisk" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /EFI/tools/gdisk_x64.efi<br />
chainloader /EFI/tools/gdisk_x64.efi<br />
}<br />
}}<br />
<br />
====== Chainloading a unified kernel image ======<br />
<br />
If you have a [[unified kernel image]] generated from following [[Secure Boot]] or other means, you can add it to the boot menu. For example:<br />
<br />
{{bc|1=<br />
menuentry "Arch Linux" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --fs-uuid ''FILESYSTEM_UUID''<br />
chainloader /EFI/Linux/Arch-linux.efi<br />
}<br />
}}<br />
<br />
===== Dual-booting =====<br />
<br />
====== GNU/Linux ======<br />
<br />
Assuming that the other distribution is on partition {{ic|sda2}}:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
Alternatively let GRUB search for the right partition by UUID or file system label:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
# assuming that UUID is 763A-9CB6<br />
search --no-floppy --set=root --fs-uuid 763A-9CB6<br />
<br />
# search by label OTHER_LINUX (make sure that partition label is unambiguous)<br />
#search --no-floppy --set=root --label OTHER_LINUX<br />
<br />
linux /boot/vmlinuz (add other options here as required, for example: root=UUID=763A-9CB6)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
If the other distribution has already a valid {{ic|/boot}} folder with installed GRUB, {{ic|grub.cfg}}, kernel and initramfs, GRUB can be instructed to load these other {{ic|grub.cfg}} files on-the-fly during boot. For example, for {{ic|hd0}} and the fourth GPT partition:<br />
<br />
{{bc|1=<br />
menuentry "configfile hd0,gpt4" {<br />
insmod part_gpt<br />
insmod btrfs<br />
insmod ext2<br />
set root='hd0,gpt4'<br />
configfile /boot/grub/grub.cfg<br />
}<br />
}}<br />
<br />
When choosing this entry, GRUB loads the {{ic|grub.cfg}} file from the other volume and displays that menu. Any environment variable changes made by the commands in file will not be preserved after {{ic|configfile}} returns. Press {{ic|Esc}} to return to the first GRUB menu.<br />
<br />
====== Windows installed in UEFI/GPT mode ======<br />
<br />
This mode determines where the Windows bootloader resides and chain-loads it after GRUB when the menu entry is selected. The main task here is finding the EFI system partition and running the bootloader from it.<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the UEFI bitness. It will not work in BIOS installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] for more information.}}<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI/GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi<br />
}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands.<br />
<br />
The {{ic|$fs_uuid}} command determines the UUID of the EFI system partition:<br />
<br />
{{hc|1=# grub-probe --target=fs_uuid ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
1ce5-7f28<br />
}}<br />
<br />
Alternatively one can run {{ic|lsblk --fs}} and read the UUID of the EFI system partition from there.<br />
<br />
The {{ic|$hints_string}} command will determine the location of the EFI system partition, in this case harddrive 0:<br />
<br />
{{hc|1=# grub-probe --target=hints_string ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1<br />
}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|''esp''}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
====== Windows installed in BIOS/MBR mode ======<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and [https://www.gnu.org/software/grub/manual/grub.html#Chain_002dloading chainloading] of partition boot sector is no longer required to boot Windows in a BIOS/MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually {{ic|C:}}). The system partition's [[Persistent block device naming#by-label|filesystem label]] is {{ic|System Reserved}} or {{ic|SYSTEM}} and the partition is only about 100 to 549 MiB in size. See [[Wikipedia:System partition and boot partition]] for more information.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of {{ic|hd0,msdos1}}.<br />
<br />
{{Note|These menu entries will work only in BIOS boot mode. It will not work in UEFI installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] .}}<br />
<br />
In both examples {{ic|''XXXXXXXXXXXXXXXX''}} is the filesystem UUID which can be found with command {{ic|lsblk --fs}}.<br />
<br />
For Windows Vista/7/8/8.1/10:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1/10 BIOS/MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr<br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /bootmgr<br />
}<br />
fi<br />
}}<br />
<br />
For Windows XP:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr<br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /ntldr<br />
}<br />
fi<br />
}}<br />
<br />
{{Note|In some cases, GRUB may be installed without a clean Windows 8, in which case you cannot boot Windows without having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it by going to Windows Recovery Console ({{ic|cmd.exe}} from install disk) and executing:<br />
<br />
X:\> bootrec.exe /fixboot<br />
X:\> bootrec.exe /RebuildBcd<br />
<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.<br />
Or you can use Boot Repair function in the Troubleshooting menu - it will not wipe out GRUB but will fix most errors.<br />
Also you would better keep plugged in both the target hard drive and your bootable device '''ONLY'''. Windows usually fails to repair boot information if any other devices are connected.<br />
}}<br />
<br />
===== Using labels =====<br />
<br />
It is possible to use file system labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, [[Persistent block device naming#by-label|make sure your file system has a label]].<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub/}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
<br />
grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub><br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the start of a partitioned disk (MBR), at the start of a partition or a partitionless disk (VBR), or as an EFI binary in the case of UEFI.<br />
<br />
==== Chainloading a partition's VBR ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partition of the first hard disk,<br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk's MBR or a partitionless disk's VBR ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod fat<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
{{ic|insmod fat}} is used for loading the FAT file system module for accessing the Windows bootloader on the EFI system partition.<br />
{{ic|(hd0,gpt4)}} or {{ic|/dev/sda4}} is the EFI system partition in this example.<br />
The entry in the {{ic|chainloader}} line specifies the path of the ''.efi'' file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[#Using the rescue console]]<br />
<br />
=== Using the rescue console ===<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
<br />
grub rescue> set prefix=(hd''X'',''Y'')/boot/grub<br />
<br />
where {{ic|''X''}} is the physical drive number and {{ic|''Y''}} is the partition number.<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path (i.e. type {{ic|1=set prefix=(hd''X'',''Y'')/grub}}).}}<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
or simply<br />
<br />
grub rescue> insmod linux<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar.<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using UEFI), again change the lines accordingly:<br />
<br />
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}<br />
<br />
set root=(hd0,5)<br />
linux (hd''X'',''Y'')/vmlinuz-linux root=/dev/sda6<br />
initrd (hd''X'',''Y'')/initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== GRUB removal ==<br />
<br />
{{Expansion|Migrating from BIOS booting to UEFI is not the only case where GRUB could be removed. Section needs to either cover how to remove GRUB installed for UEFI booting or it should be removed altogether as too trivial.}}<br />
<br />
In general, in order to remove ''grub'', one has to do the installation steps in reverse order. Perhaps cleaning any left over at the end. However, before doing anything, one has to decide if, and how, the machine will boot after the removal. Assuming one removes ''grub'' because they would like to use another boot loader, a safe, though a bit difficult, method is to make sure the other boot loader is working before removing ''grub''.<br />
<br />
In any case, even when removing ''grub'' before installing another boot loader, for the UEFI case, run:<br />
<br />
$ efibootmgr<br />
<br />
And verify the other boot loader is listed in the {{ic|BootOrder}} line. If ''grub'' was not removed, the other boot loader should be listed before ''grub''. If ''grub'' is already removed, ''grub'' should not be mentioned in that line. But note this is only a necessary, but not sufficient, condition for the machine to boot with the other boot loader. Neither it is a sufficient condition for the full removal of ''grub''.<br />
<br />
For both UEFI and non UEFI machines, {{ic|grub-install}} was manually run as part of the installation of ''grub''. One of its jobs for the UEFI case was to run the equivalent of {{ic|efibootmgr --create}}. As part of ''grub'' removal, one has to remove the products of {{ic|grub-install}}. The opposite of {{ic|efibootmgr --create}} is {{ic|efibootmgr --delete-bootnum}}, or an equivalent program. One way to obtain the number of the boot entry for the {{ic|efibootmgr --delete-bootnum}} command is from the output of {{ic|efibootmgr}} (with no arguments).<br />
<br />
{{ic|grub-install}} creates the {{ic|/boot/grub}} directory that needs to be removed manually. Though some users will want to keep it, should they want to install ''grub'' again.<br />
<br />
After migrating to GPT/UEFI one may want to remove the [[Partitioning#Master Boot Record (bootstrap code)|MBR boot code]] [[dd#Remove bootloader|using dd]]:<br />
<br />
# dd if=/dev/zero of=/dev/sd''X'' bs=440 count=1<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unsupported file systems ===<br />
<br />
In case that GRUB does not support the root file system, an alternative {{ic|/boot}} partition with a supported file system must be created. In some cases, the development version of GRUB {{aur|grub-git}} may have native support for the file system.<br />
<br />
If GRUB is used with an unsupported file system it is not able to extract the [[UUID]] of your drive so it uses classic non-persistent {{ic|/dev/''sdXx''}} names instead. In this case you might have to manually edit {{ic|/boot/grub/grub.cfg}} and replace {{ic|1=root=/dev/''sdXx''}} with {{ic|1=root=UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}}. You can use the {{ic|blkid}} command to get the UUID of your device, see [[Persistent block device naming]].<br />
<br />
While GRUB supports [[F2FS]] since version 2.0.4, it cannot correctly read its boot files from an F2FS partition that was created with the {{ic|extra_attr}} flag enabled.<br />
<br />
=== Enable debug messages ===<br />
<br />
{{Note|This change is overwritten when [[#Generate the main configuration file]].}}<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== UEFI ===<br />
<br />
==== Common installation errors ====<br />
<br />
* If you have a problem when running ''grub-install'' with ''sysfs'' or ''procfs'' and it says you must run {{ic|modprobe efivarfs}}, try [[Unified Extensible Firmware Interface#Mount efivarfs]].<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* If after running grub-install you are told your partition does not look like an EFI partition then the partition is most likely not {{ic|Fat32}}.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
As another example of creating a GRUB entry in the firmware boot manager, consider {{ic|efibootmgr -c}}. This assumes that /dev/sda1 is the EFI System Partition, and is mounted at /boot/efi. Which are the default behavior of {{ic|efibootmgr}}. It creates a new boot option, called "Linux", and puts it at the top of the boot order list. Options may be passed to modify the default behavior. The default OS Loader is \EFI\arch\grub.efi.<br />
<br />
==== Drop to rescue shell ====<br />
<br />
If GRUB loads but drops into the rescue shell with no errors, it can be due to one of these two reasons:<br />
<br />
* It may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing,<br />
* It also happens if the boot partition, which is hardcoded into the {{ic|grubx64.efi}} file, has changed.<br />
<br />
==== GRUB UEFI not loaded ====<br />
<br />
An example of a working UEFI:<br />
<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EFI\GRUB\grubx64.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\shellx64.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grubx64.efi)<br />
<br />
==== Default/fallback boot path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to install GRUB at the default/fallback boot path:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' '''--removable'''<br />
<br />
Alternatively you can move an already installed GRUB EFI executable to the default/fallback path:<br />
<br />
# mv ''esp''/EFI/grub ''esp''/EFI/BOOT<br />
# mv ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/BOOTX64.EFI<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions may have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}}.<br />
<br />
=== Warning when installing in chroot ===<br />
<br />
When installing GRUB on a LVM system in a chroot environment (e.g. during system installation), you may receive warnings like<br />
<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
<br />
or<br />
<br />
WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.<br />
<br />
This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
<br />
=== GRUB loads slowly ===<br />
<br />
GRUB can take a long time to load when disk space is low. Check if you have sufficient free disk space on your {{ic|/boot}} or {{ic|/}} partition when you are having problems.<br />
<br />
=== error: unknown filesystem ===<br />
<br />
GRUB may output {{ic|error: unknown filesystem}} and refuse to boot for a few reasons. If you are certain that all [[UUID]]s are correct and all filesystems are valid and supported, it may be because your [[#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] is located outside the first 2 TiB of the drive [https://bbs.archlinux.org/viewtopic.php?id=195948]. Use a partitioning tool of your choice to ensure this partition is located fully within the first 2 TiB, then reinstall and reconfigure GRUB.<br />
<br />
This error might also be caused by an [[ext4]] filesystem having unsupported features set:<br />
* {{ic|large_dir}} - unsupported.<br />
* {{ic|metadata_csum_seed}} - will be supported in GRUB 2.11 ([https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 commit]).<br />
<br />
{{Warning|Make sure to check GRUB support for new [[file system]] features before you enable them on your {{ic|/boot}} file system.}}<br />
<br />
=== grub-reboot not resetting ===<br />
<br />
GRUB seems to be unable to write to root BTRFS partitions [https://bbs.archlinux.org/viewtopic.php?id=166131]. If you use grub-reboot to boot into another entry it will therefore be unable to update its on-disk environment. Either run grub-reboot from the other entry (for example when switching between various distributions) or consider a different file system. You can reset a "sticky" entry by executing {{ic|grub-editenv create}} and setting {{ic|1=GRUB_DEFAULT=0}} in your {{ic|/etc/default/grub}} (do not forget {{ic|grub-mkconfig -o /boot/grub/grub.cfg}}).<br />
<br />
=== Old BTRFS prevents installation ===<br />
<br />
If a drive is formatted with BTRFS without creating a partition table (eg. /dev/sdx), then later has partition table written to, there are parts of the BTRFS format that persist. Most utilities and OS's do not see this, but GRUB will refuse to install, even with --force<br />
<br />
# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..<br />
# grub-install: error: filesystem `btrfs' does not support blocklists.<br />
<br />
You can zero the drive, but the easy solution that leaves your data alone is to erase the BTRFS superblock with {{ic|wipefs -o 0x10040 /dev/sdx}}<br />
<br />
=== Windows 8/10 not found ===<br />
<br />
A setting in Windows 8/10 called "Hiberboot", "Hybrid Boot" or "Fast Boot" can prevent the Windows partition from being mounted, so {{ic|grub-mkconfig}} will not find a Windows install. Disabling Hiberboot in Windows will allow it to be added to the GRUB menu.<br />
<br />
=== VirtualBox EFI mode ===<br />
<br />
For VirtualBox < 6.1, install GRUB to the [[#Default/fallback boot path|default/fallback boot path]].<br />
<br />
See also [[VirtualBox#Installation in EFI mode on VirtualBox < 6.1]].<br />
<br />
=== Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds ===<br />
<br />
If grub-mkconfig hangs and gives error: {{ic|WARNING: Device /dev/''xxx'' not initialized in udev database even after waiting 10000000 microseconds}}.<br />
<br />
You may need to provide {{ic|/run/lvm/}} access to the chroot environment using:<br />
<br />
# mkdir /mnt/hostlvm<br />
# mount --bind /run/lvm /mnt/hostlvm<br />
# arch-chroot /mnt<br />
# ln -s /hostlvm /run/lvm<br />
<br />
See {{Bug|61040}} and [https://bbs.archlinux.org/viewtopic.php?pid=1820949#p1820949 workaround].<br />
<br />
=== GRUB rescue and encrypted /boot ===<br />
<br />
When using an [[#Encrypted /boot|encrypted /boot]], and you fail to input a correct password, you will be dropped in grub-rescue prompt.<br />
<br />
This grub-rescue prompt has limited capabilities. Use the following commands to complete the boot:<br />
{{bc|<br />
grub rescue> cryptomount <partition><br />
grub rescue> insmod normal<br />
grub rescue> normal<br />
}}<br />
<br />
See [https://blog.stigok.com/2017/12/29/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html this blog post] for a better description.<br />
<br />
=== GRUB is installed but the menu is not shown at boot ===<br />
<br />
Check {{ic|/etc/default/grub}} if {{ic|GRUB_TIMEOUT}} is set to {{ic|0}}, in which case set it to a positive number: it sets the number of seconds before the default GRUB entry is loaded. Also check if {{ic|GRUB_TIMEOUT_STYLE}} is set to {{ic|hidden}} and set it to {{ic|menu}}, so that the menu will be shown by default. Then [[#Generate the main configuration file|regenerate the main configuration file]] and reboot to check if it worked.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:GNU GRUB]]<br />
* [https://www.gnu.org/software/grub/manual/grub.html Official GRUB Manual]<br />
* [https://help.ubuntu.com/community/Grub2 Ubuntu wiki page for GRUB]<br />
* [https://help.ubuntu.com/community/UEFIBooting GRUB wiki page describing steps to compile for UEFI systems]<br />
* [[Wikipedia:BIOS Boot partition]]<br />
* [https://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme How to configure GRUB]<br />
* [https://archived.forum.manjaro.org/t/detecting-efi-files-and-booting-them-from-grub/38083 Detecting efi files and booting them from grub]</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=LVM&diff=746002LVM2022-09-12T17:40:37Z<p>DasMenschy: /* Disadvantages */ add warning: shrinking/resizing physical volumes is almost impossible</p>
<hr />
<div>[[Category:Storage virtualization]]<br />
[[de:LVM]]<br />
[[es:LVM]]<br />
[[ja:LVM]]<br />
[[pt:LVM]]<br />
[[zh-hans:LVM]]<br />
{{Related articles start}}<br />
{{Related|Install Arch Linux on LVM}}<br />
{{Related|LVM on software RAID}}<br />
{{Related|dm-crypt/Encrypting an entire system#LVM on LUKS}}<br />
{{Related|dm-crypt/Encrypting an entire system#LUKS on LVM}}<br />
{{Related|Resizing LVM-on-LUKS}}<br />
{{Related|Create root filesystem snapshots with LVM}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Logical Volume Manager (Linux)]]:<br />
<br />
:Logical Volume Manager (LVM) is a [[Wikipedia:device mapper|device mapper]] framework that provides [[Wikipedia:logical volume management|logical volume management]] for the [[Wikipedia:Linux kernel|Linux kernel]].<br />
<br />
== Background ==<br />
<br />
=== LVM building blocks ===<br />
<br />
Logical Volume Management utilizes the kernel's [http://sources.redhat.com/dm/ device-mapper] feature to provide a system of [[partition]]s independent of underlying disk layout. With LVM you abstract your storage and have "virtual partitions", making [[#Resizing the logical volume and file system separately|extending/shrinking]] easier (subject to potential filesystem limitations).<br />
<br />
Virtual partitions allow addition and removal without worry of whether you have enough contiguous space on a particular disk, getting caught up fdisking a disk in use (and wondering whether the kernel is using the old or new partition table), or, having to move other partitions out of the way.<br />
<br />
Basic building blocks of LVM:<br />
<br />
; Physical volume (PV): Unix block device node, usable for storage by LVM. Examples: a hard disk, an [[MBR]] or [[GPT]] partition, a loopback file, a device mapper device (e.g. [[dm-crypt]]). It hosts an LVM header.<br />
; Volume group (VG): Group of PVs that serves as a container for LVs. PEs are allocated from a VG for a LV.<br />
; Logical volume (LV): "Virtual/logical partition" that resides in a VG and is composed of PEs. LVs are Unix block devices analogous to physical partitions, e.g. they can be directly formatted with a [[file system]].<br />
; Physical extent (PE): The smallest contiguous extent (default 4 MiB) in the PV that can be assigned to a LV. Think of PEs as parts of PVs that can be allocated to any LV.<br />
<br />
Example:<br />
<br />
{{Text art|<nowiki><br />
Physical disks<br />
<br />
Disk1 (/dev/sda):<br />
┌──────────────────────────────────────┬─────────────────────────────────────┐<br />
│ Partition1 50 GiB (Physical volume) │ Partition2 80 GiB (Physical volume) │<br />
│ /dev/sda1 │ /dev/sda2 │<br />
└──────────────────────────────────────┴─────────────────────────────────────┘<br />
<br />
Disk2 (/dev/sdb):<br />
┌──────────────────────────────────────┐<br />
│ Partition1 120 GiB (Physical volume) │<br />
│ /dev/sdb1 │<br />
└──────────────────────────────────────┘<br />
</nowiki>}}<br />
<br />
{{Text art|<nowiki><br />
LVM logical volumes<br />
<br />
Volume Group1 (/dev/MyVolGroup/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):<br />
┌─────────────────────────┬─────────────────────────┬──────────────────────────┐<br />
│ Logical volume1 15 GiB │ Logical volume2 35 GiB │ Logical volume3 200 GiB │<br />
│ /dev/MyVolGroup/rootvol │ /dev/MyVolGroup/homevol │ /dev/MyVolGroup/mediavol │<br />
└─────────────────────────┴─────────────────────────┴──────────────────────────┘<br />
</nowiki>}}<br />
<br />
{{Note|Logical volumes are accessible at both {{ic|/dev/''VolumeGroupName''/''LogicalVolumeName''}} and {{ic|/dev/mapper/''VolumeGroupName-LogicalVolumeName''}}. However, {{man|8|lvm|VALID NAMES}} recommends the former format for "software and scripts" (e.g. [[fstab]]) since the latter is intended for "internal use" and subject to possible "change between releases and distributions".}}<br />
<br />
=== Advantages ===<br />
<br />
LVM gives you more flexibility than just using normal hard drive partitions:<br />
<br />
* Use any number of disks as one big disk.<br />
* Have logical volumes stretched over several disks.<br />
* Create small logical volumes and resize them "dynamically" as they get filled up.<br />
* Resize logical volumes regardless of their order on disk. It does not depend on the position of the LV within VG, there is no need to ensure surrounding available space.<br />
* Resize/create/delete logical and physical volumes online. File systems on them still need to be resized, but some (such as ext4) support online resizing.<br />
* Online/live migration of LV being used by services to different disks without having to restart services.<br />
* Snapshots allow you to backup a frozen copy of the file system, while keeping service downtime to a minimum.<br />
* Support for unlocking separate volumes without having to enter a key multiple times on boot ([[dm-crypt/Encrypting an entire system#LVM on LUKS|make LVM on top of LUKS]]).<br />
* Built-in support for caching of frequently used data ({{man|7|lvmcache}}).<br />
<br />
=== Disadvantages ===<br />
<br />
* Additional steps in setting up the system, more complicated. Requires (multiple) daemons to constantly run.<br />
* If dual-booting, note that Windows does not support LVM; you will be unable to access any LVM partitions from Windows.<br />
* If your physical volumes are not on a RAID-1, RAID-5 or RAID-6 losing one disk ''can'' lose one or more logical volumes if you span (or extend) your logical volumes across multiple non-redundant disks.<br />
* You cannot (easily) shrink the space used by the logical volume manager, meaning the physical volumes used for the logical volumes. If the physical extents are scattered across the physical volume until the end, it is not possible to shrink the physical volume with the scripts provided on the Arch Wiki. If you want to dual-boot with other operating systems (e.g. with Microsoft Windows), the only space left on the device for Microsoft Windows is the space not used by LVM / not used as physical volume.<br />
<br />
=== Getting started ===<br />
<br />
Make sure the {{pkg|lvm2}} package is [[install]]ed.<br />
<br />
If you have LVM volumes not activated via the [[initramfs]], [[enable]] {{ic|lvm-monitoring.service}}, which is provided by the {{pkg|lvm2}} package.<br />
<br />
== Volume operations ==<br />
<br />
=== Physical volumes ===<br />
<br />
==== Creating ====<br />
<br />
To create a PV on {{ic|/dev/sda1}}, run:<br />
<br />
# pvcreate /dev/sda1<br />
<br />
You can check the PV is created using the following command:<br />
<br />
# pvs<br />
<br />
==== Growing ====<br />
<br />
After extending or prior to reducing the size of a device that has a physical volume on it, you need to grow or shrink the PV using {{man|8|pvresize}}.<br />
<br />
To expand the PV on {{ic|/dev/sda1}} after enlarging the [[partition]], run:<br />
<br />
# pvresize /dev/sda1<br />
<br />
This will automatically detect the new size of the device and extend the PV to its maximum.<br />
<br />
{{Note|This command can be done while the volume is online.}}<br />
<br />
==== Shrinking ====<br />
<br />
To shrink a physical volume prior to reducing its underlying device, add the {{ic|--setphysicalvolumesize ''size''}} parameters to the command, ''e.g.'':<br />
<br />
# pvresize --setphysicalvolumesize 40G /dev/sda1<br />
<br />
The above command may leave you with this error:<br />
<br />
/dev/sda1: cannot resize to 25599 extents as later ones are allocated.<br />
0 physical volume(s) resized / 1 physical volume(s) not resized<br />
<br />
Indeed ''pvresize'' will refuse to shrink a PV if it has allocated extents after where its new end would be. One needs to run [[#Move physical extents|pvmove]] beforehand to relocate these elsewhere in the volume group if there is sufficient free space.<br />
<br />
===== Move physical extents =====<br />
<br />
Before moving free extents to the end of the volume, one must run {{ic|pvdisplay -v -m}} to see physical segments. In the below example, there is one physical volume on {{ic|/dev/sdd1}}, one volume group {{ic|vg1}} and one logical volume {{ic|backup}}.<br />
<br />
{{hc|# pvdisplay -v -m|<br />
Finding all volume groups.<br />
Using physical volume(s) on command line.<br />
--- Physical volume ---<br />
PV Name /dev/sdd1<br />
VG Name vg1<br />
PV Size 1.52 TiB / not usable 1.97 MiB<br />
Allocatable yes <br />
PE Size 4.00 MiB<br />
Total PE 399669<br />
Free PE 153600<br />
Allocated PE 246069<br />
PV UUID MR9J0X-zQB4-wi3k-EnaV-5ksf-hN1P-Jkm5mW<br />
<br />
--- Physical Segments ---<br />
Physical extent 0 to 153600:<br />
FREE<br />
Physical extent 153601 to 307199:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 1 to 153599<br />
Physical extent 307200 to 307200:<br />
FREE<br />
Physical extent 307201 to 399668:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 153601 to 246068<br />
}}<br />
<br />
One can observe {{ic|FREE}} space are split across the volume. To shrink the physical volume, we must first move all used segments to the beginning.<br />
<br />
Here, the first free segment is from 0 to 153600 and leaves us with 153601 free extents. We can now move this segment number from the last physical extent to the first extent. The command will thus be:<br />
<br />
{{hc|# pvmove --alloc anywhere /dev/sdd1:307201-399668 /dev/sdd1:0-92467|<br />
/dev/sdd1: Moved: 0.1 %<br />
/dev/sdd1: Moved: 0.2 %<br />
...<br />
/dev/sdd1: Moved: 99.9 %<br />
/dev/sdd1: Moved: 100.0 %<br />
}}<br />
<br />
{{Note|1=<nowiki/><br />
* This command moves 399668 - 307201 + 1 = 92468 PEs '''from''' the last segment '''to''' the first segment. This is possible as the first segment encloses 153600 free PEs, which can contain the 92467 - 0 + 1 = 92468 moved PEs.<br />
* The {{ic|--alloc anywhere}} option is used as we move PEs inside the same partition. In case of different partitions, the command would look something like this: {{bc|# pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999}}<br />
* This command may take a long time (one to two hours) in case of large volumes. It might be a good idea to run this command in a [[tmux]] or [[GNU Screen]] session. Any unwanted stop of the process could be fatal.<br />
* Once the operation is complete, run [[fsck]] to make sure your file system is valid.<br />
}}<br />
<br />
===== Resize physical volume =====<br />
<br />
Once all your free physical segments are on the last physical extents, run {{ic|vgdisplay}} with root privileges and see your free PE.<br />
<br />
Then you can now run again the command:<br />
<br />
# pvresize --setphysicalvolumesize ''size'' ''PhysicalVolume''<br />
<br />
See the result:<br />
<br />
{{hc|# pvs|<br />
PV VG Fmt Attr PSize PFree <br />
/dev/sdd1 vg1 lvm2 a-- 1t 500g<br />
}}<br />
<br />
===== Resize partition =====<br />
<br />
Last, you need to shrink the partition with your favorite [[Partitioning#Partitioning tools|partitioning tool]].<br />
<br />
=== Volume groups ===<br />
<br />
==== Creating a volume group ====<br />
<br />
To create a VG {{ic|MyVolGroup}} with an associated PV {{ic|/dev/sdb1}}, run:<br />
<br />
# vgcreate MyVolGroup /dev/sdb1<br />
<br />
You can check the VG {{ic|MyVolGroup}} is created using the following command:<br />
<br />
# vgs<br />
<br />
You can bind multiple PVs when creating a VG like this:<br />
<br />
# vgcreate MyVolGroup /dev/sdb1 /dev/sdb2<br />
<br />
==== Activating a volume group ====<br />
<br />
{{Note|You can restrict the volumes that are activated automatically by setting the {{ic|auto_activation_volume_list}} in {{ic|/etc/lvm/lvm.conf}}. If in doubt, leave this option commented out.}}<br />
<br />
# vgchange -a y MyVolGroup<br />
<br />
By default, this will reactivate the volume group when applicable. For example, if you had a drive failure in a mirror and you swapped the drive; and ran (1) {{ic|pvcreate}}, (2) {{ic|vgextend}} and (3) {{ic|vgreduce --removemissing --force}}.<br />
<br />
==== Repairing a volume group ====<br />
<br />
To start the rebuilding process of the degraded mirror array in this example, you would run:<br />
<br />
# lvconvert --repair /dev/MyVolGroup/mirror<br />
<br />
You can monitor the rebuilding process (Cpy%Sync Column output) with:<br />
<br />
# lvs -a -o +devices<br />
<br />
==== Deactivating a volume group ====<br />
<br />
Just invoke <br />
<br />
# vgchange -a n MyVolGroup<br />
<br />
This will deactivate the volume group and allow you to unmount the container it is stored in.<br />
<br />
==== Renaming a volume group ====<br />
<br />
Use the {{man|8|vgrename}} command to rename an existing volume group.<br />
<br />
Either of the following commands renames the existing volume group {{ic|MyVolGroup}} to {{ic|my_volume_group}}<br />
<br />
# vgrename /dev/MyVolGroup /dev/my_volume_group<br />
<br />
# vgrename MyVolGroup my_volume_group<br />
<br />
Make sure to update all configuration files (e.g. {{ic|/etc/fstab}} or {{ic|/etc/crypttab}}) that reference the renamed volume group.<br />
<br />
==== Add physical volume to a volume group ====<br />
<br />
You first create a new physical volume on the block device you wish to use, then extend your volume group<br />
<br />
# pvcreate /dev/sdb1<br />
# vgextend MyVolGroup /dev/sdb1<br />
<br />
This of course will increase the total number of physical extents on your volume group, which can be allocated by logical volumes as you see fit.<br />
<br />
{{Note|It is considered good form to have a [[partition table]] on your storage medium below LVM. Use the appropriate partition type: {{ic|8e}} for MBR, and {{ic|E6D6D379-F507-44C2-A23C-238F2A3DF928}} for GPT partitions.}}<br />
<br />
==== Remove partition from a volume group ====<br />
<br />
If you created a logical volume on the partition, [[#Removing a logical volume|remove]] it first.<br />
<br />
All of the data on that partition needs to be moved to another partition. Fortunately, LVM makes this easy:<br />
<br />
# pvmove /dev/sdb1<br />
<br />
If you want to have the data on a specific physical volume, specify that as the second argument to {{ic|pvmove}}:<br />
<br />
# pvmove /dev/sdb1 /dev/sdf1<br />
<br />
Then the physical volume needs to be removed from the volume group:<br />
<br />
# vgreduce MyVolGroup /dev/sdb1<br />
<br />
Or remove all empty physical volumes:<br />
<br />
# vgreduce --all MyVolGroup<br />
<br />
For example: if you have a bad disk in a group that cannot be found because it has been removed or failed:<br />
<br />
# vgreduce --removemissing --force MyVolGroup<br />
<br />
And lastly, if you want to use the partition for something else, and want to avoid LVM thinking that the partition is a physical volume:<br />
<br />
# pvremove /dev/sdb1<br />
<br />
=== Logical volumes ===<br />
<br />
{{Note|{{man|8|lvresize}} provides more or less the same options as the specialized {{man|8|lvextend}} and {{man|8|lvreduce}} commands, while allowing to do both types of operation. Notwithstanding this, all those utilities offer a {{ic|-r}}/{{ic|--resizefs}} option which allows to resize the file system together with the LV using {{man|8|fsadm}} (''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] supported). Therefore it may be easier to simply use {{ic|lvresize}} for both operations and use {{ic|--resizefs}} to simplify things a bit, except if you have specific needs or want full control over the process.}}<br />
<br />
{{Warning|While enlarging a file system can often be done on-line (''i.e.'' while it is mounted), even for the root partition, shrinking will nearly always require to first unmount the file system so as to prevent data loss. Make sure your file system supports what you are trying to do.}}<br />
<br />
{{Tip|If a logical volume will be formatted with [[ext4]], leave at least 256 MiB free space in the volume group to allow using {{man|8|e2scrub}}.}}<br />
<br />
==== Creating a logical volume ====<br />
<br />
To create a LV {{ic|homevol}} in a VG {{ic|MyVolGroup}} with 300 GiB of capacity, run:<br />
<br />
# lvcreate -L 300G MyVolGroup -n homevol<br />
<br />
or, to create a LV {{ic|homevol}} in a VG {{ic|MyVolGroup}} with the rest of capacity, run:<br />
<br />
# lvcreate -l +100%FREE MyVolGroup -n homevol<br />
<br />
The new LV will appear as {{ic|/dev/MyVolGroup/homevol}}. Now you can [[format]] the LV with an appropriate file system.<br />
<br />
You can check the LV is created using the following command:<br />
<br />
# lvs<br />
<br />
==== Renaming a logical volume ====<br />
<br />
To rename an existing logical volume, use the {{man|8|lvrename}} command.<br />
<br />
Either of the following commands renames logical volume {{ic|old_vol}} in volume group {{ic|MyVolGroup}} to {{ic|new_vol}}.<br />
<br />
# lvrename /dev/MyVolGroup/old_vol /dev/MyVolGroup/new_vol<br />
<br />
# lvrename MyVolGroup old_vol new_vol<br />
<br />
Make sure to update all configuration files (e.g. {{ic|/etc/fstab}} or {{ic|/etc/crypttab}}) that reference the renamed logical volume.<br />
<br />
==== Resizing the logical volume and file system in one go ====<br />
<br />
{{Note|Only ''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] [[file systems]] are supported. For a different type of file system see [[#Resizing the logical volume and file system separately]].}}<br />
<br />
Extend the logical volume {{ic|mediavol}} in {{ic|MyVolGroup}} by 10 GiB and resize its file system ''all at once'':<br />
<br />
# lvresize -L +10G --resizefs MyVolGroup/mediavol<br />
<br />
Set the size of logical volume {{ic|mediavol}} in {{ic|MyVolGroup}} to 15 GiB and resize its file system ''all at once'':<br />
<br />
# lvresize -L 15G --resizefs MyVolGroup/mediavol<br />
<br />
If you want to fill all the free space on a volume group, use the following command:<br />
<br />
# lvresize -l +100%FREE --resizefs MyVolGroup/mediavol<br />
<br />
See {{man|8|lvresize}} for more detailed options.<br />
<br />
==== Resizing the logical volume and file system separately ====<br />
<br />
For file systems not supported by {{man|8|fsadm}} will need to use the [[File systems#Types of file systems|appropriate utility]] to resize the file system before shrinking the logical volume or after expanding it.<br />
<br />
To extend logical volume {{ic|mediavol}} within volume group {{ic|MyVolGroup}} by 2 GiB ''without'' touching its file system:<br />
<br />
# lvresize -L +2G MyVolGroup/mediavol<br />
<br />
Now expand the file system ([[ext4]] in this example) to the maximum size of the underlying logical volume:<br />
<br />
# resize2fs /dev/MyVolGroup/mediavol<br />
<br />
To reduce the size of logical volume {{ic|mediavol}} in {{ic|MyVolGroup}} by 500 MiB, first calculate the resulting file system size and shrink the file system ([[ext4]] in this example) to the new size:<br />
<br />
# resize2fs /dev/MyVolGroup/mediavol ''NewSize''<br />
<br />
When the file system is shrunk, reduce the size of logical volume:<br />
<br />
# lvresize -L -500M MyVolGroup/mediavol<br />
<br />
To calculate the exact logical volume size for ''ext2'', [[ext3]], [[ext4]] file systems, use a simple formula: {{ic|1=LVM_EXTENTS = FS_BLOCKS × FS_BLOCKSIZE ÷ LVM_EXTENTSIZE}}.<br />
<br />
{{hc|# tune2fs -l /dev/MyVolGroup/mediavol {{!}} grep Block|<br />
Block count: 102400000<br />
Block size: 4096<br />
Blocks per group: 32768<br />
}}<br />
<br />
{{hc|# vgdisplay MyVolGroup {{!}} grep "PE Size"|<br />
PE Size 4.00 MiB<br />
}}<br />
<br />
{{Note|The file system block size is in bytes. Make sure to use the same units for both block and extent size.}}<br />
<br />
102400000 blocks × 4096 bytes/block ÷ 4 MiB/extent = 100000 extents<br />
<br />
Passing {{ic|--resizefs}} will confirm that the correctness.<br />
<br />
{{hc|# lvreduce -l 100000 --resizefs /dev/MyVolGroup/mediavol|<br />
...<br />
The filesystem is already 102400000 (4k) blocks long. Nothing to do!<br />
...<br />
Logical volume sysvg/root successfully resized.<br />
}}<br />
<br />
See {{man|8|lvresize}} for more detailed options.<br />
<br />
==== Removing a logical volume ====<br />
<br />
{{Warning|Before you remove a logical volume, make sure to move all data that you want to keep somewhere else; otherwise, it will be lost!}}<br />
<br />
First, find out the name of the logical volume you want to remove. You can get a list of all logical volumes with:<br />
<br />
# lvs<br />
<br />
Next, look up the mountpoint of the chosen logical volume:<br />
<br />
$ lsblk<br />
<br />
Then unmount the filesystem on the logical volume:<br />
<br />
# umount /''mountpoint''<br />
<br />
Finally, remove the logical volume:<br />
<br />
# lvremove ''volume_group''/''logical_volume''<br />
<br />
For example:<br />
<br />
# lvremove MyVolGroup/homevol<br />
<br />
Confirm by typing in {{ic|y}}.<br />
<br />
Make sure to update all configuration files (e.g. {{ic|/etc/fstab}} or {{ic|/etc/crypttab}}) that reference the removed logical volume.<br />
<br />
You can verify the removal of the logical volume by typing {{ic|lvs}} as root again (see first step of this section).<br />
<br />
== Snapshots ==<br />
<br />
LVM supports CoW (Copy-on-Write) snapshots. A CoW snapshot initially points to the original data. When data blocks are overwritten, the original copy is left intact and the new blocks are written elsewhere on-disk. This has several desirable properties:<br />
* Creating snapshots is fast, because it does not copy data (just the much shorter list of pointers to the on-disk locations).<br />
* Snapshots require just enough free space to hold the new data blocks (plus a negligible amount for the pointers to the new blocks). For example, a snapshot of 35 GiB of data, where you write only 2 GiB (on both the original and snapshot), only requires 2 GiB of free space.<br />
<br />
LVM snapshots are at the block level. They make a new block device, with no apparent relationship to the original except when dealing with the LVM tools. Therefore, deleting files in the original copy does not free space in the snapshots. If you need filesystem-level snapshots, you rather need btrfs, ZFS or bcache.<br />
<br />
{{Warning|<br />
* A CoW snapshot '''is not a backup''', because it does not make a second copy of the original data. For example, a damaged disk sector that affects original data also affects the snapshots. That said, a snapshot can be helpful while using other tools to make backups, as outlined [[#Backups|below]].<br />
* Btrfs expects different filesystems to have different UUIDs. If you snapshot a LVM volume that contains a btrfs filesystem, make sure to change the UUID of the original or the copy, before both are mounted (or made visible to the kernel, for example if an unrelated daemon triggers a ''btrfs device scan''). For details see [https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices btrfs wiki Gotcha's].<br />
}}<br />
<br />
=== Configuration ===<br />
<br />
You create snapshot logical volumes just like normal ones.<br />
<br />
# lvcreate --size 100M --snapshot --name snap01vol /dev/MyVolGroup/lvol<br />
<br />
With that volume, you may modify less than 100 MiB of data, before the snapshot volume fills up.<br />
<br />
Reverting the modified {{ic|lvol}} logical volume to the state when the {{ic|snap01vol}} snapshot was taken can be done with<br />
<br />
# lvconvert --merge /dev/MyVolGroup/snap01vol<br />
<br />
In case the origin logical volume is active, merging will occur on the next reboot (merging can be done even from a LiveCD). <br />
<br />
{{Note|The snapshot will no longer exist after merging.}}<br />
<br />
Also multiple snapshots can be taken and each one can be merged with the origin logical volume at will.<br />
<br />
=== Backups ===<br />
<br />
A snapshot provides a frozen copy of a file system to make backups. For example, a backup taking two hours provides a more consistent image of the file system than directly backing up the partition.<br />
<br />
The snapshot can be mounted and backed up with [[dd]] or [[tar]]. The size of the backup file done with ''dd'' will be the size of the files residing on the snapshot volume. <br />
To restore just create a snapshot, mount it, and write or extract the backup to it. And then merge it with the origin.<br />
<br />
See [[Create root filesystem snapshots with LVM]] for automating the creation of clean root file system snapshots during system startup for backup and rollback.<br />
<br />
{{Expansion|Show scripts to automate snapshots of root before updates, to rollback... updating {{ic|menu.lst}} to boot snapshots (maybe in a separate article?)}}<br />
<br />
== Encryption ==<br />
<br />
See [[dm-crypt/Encrypting an entire system#LUKS on LVM]] and [[dm-crypt/Encrypting an entire system#LVM on LUKS]] for the possible schemes of combining LUKS with LVM.<br />
<br />
== Cache ==<br />
<br />
From {{man|7|lvmcache}}:<br />
<br />
: The cache logical volume type uses a small and fast LV to improve the performance of a large and slow LV. It does this by storing the frequently used blocks on the faster LV. LVM refers to the small fast LV as a cache pool LV. The large slow LV is called the origin LV. Due to requirements from dm-cache (the kernel driver), LVM further splits the cache pool LV into two devices - the cache data LV and cache metadata LV. The cache data LV is where copies of data blocks are kept from the origin LV to increase speed. The cache metadata LV holds the accounting information that specifies where data blocks are stored (e.g. on the origin LV or on the cache data LV). Users should be familiar with these LVs if they wish to create the best and most robust cached logical volumes. All of these associated LVs must be in the same VG.<br />
<br />
=== Create cache ===<br />
<br />
Convert your fast disk ({{ic|/dev/''fastdisk''}}) to PV and add to your existing VG ({{ic|MyVolGroup}}):<br />
<br />
# vgextend MyVolGroup /dev/''fastdisk''<br />
<br />
Create a cache pool with automatic meta data on {{ic|/dev/''fastdisk''}} and convert the existing LV {{ic|MyVolGroup/rootvol}} to a cached volume, all in one step:<br />
<br />
# lvcreate --type cache --cachemode writethrough -l 100%FREE -n root_cachepool MyVolGroup/rootvol /dev/''fastdisk''<br />
<br />
{{Tip|Instead of using {{ic|-l 100%FREE}} to allocate 100% of available space from PV {{ic|/dev/''fastdisk''}}, you can use {{ic|-L 20G}} instead to allocate only 20 GiB for cachepool.}}<br />
<br />
Cachemode has two possible options:<br />
<br />
* {{ic|writethrough}} ensures that any data written will be stored both in the cache pool LV and on the origin LV. The loss of a device associated with the cache pool LV in this case would not mean the loss of any data;<br />
* {{ic|writeback}} ensures better performance, but at the cost of a higher risk of data loss in case the drive used for cache fails.<br />
<br />
If a specific {{ic|--cachemode}} is not indicated, the system will assume {{ic|writethrough}} as default.<br />
<br />
=== Remove cache ===<br />
<br />
If you ever need to undo the one step creation operation above:<br />
<br />
# lvconvert --uncache MyVolGroup/rootvol<br />
<br />
This commits any pending writes still in the cache back to the origin LV, then deletes the cache. Other options are available and described in {{man|7|lvmcache}}.<br />
<br />
== RAID ==<br />
<br />
LVM may be used to create a [[RAID#Implementation|software RAID]]. It is a good choice if the user does not have hardware RAID and was planning on using LVM anyway. From {{man|7|lvmraid}}:<br />
: {{man|8|lvm}} RAID is a way to create a Logical Volume (LV) that uses multiple physical devices to improve performance or tolerate device failures. In LVM, the physical devices are Physical Volumes (PVs) in a single Volume Group (VG).<br />
<br />
LVM RAID supports RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 and RAID 10. See [[Wikipedia:Standard RAID levels]] for details on each level.<br />
<br />
{{Warning|When using the {{ic|lvm2}} [[mkinitcpio]] hook, make sure to [[Install Arch Linux on LVM#Configure mkinitcpio for RAID|include the RAID kernel modules in the initramfs]]. This must be done regardless whether the root volume is on LVM RAID or not, as after boot ''pvscan'' will not retry activating devices it could not activate in the initramfs phase. See {{Bug|71385}}.}}<br />
<br />
{{Tip|[[mdadm]] may also be used to create a software RAID. It is arguably simpler, more popular, and easier to setup.}}<br />
<br />
=== Setup RAID ===<br />
<br />
Create physical volumes:<br />
<br />
# pvcreate /dev/sda2 /dev/sdb2<br />
<br />
Create volume group on the physical volumes:<br />
<br />
# vgcreate MyVolGroup /dev/sda2 /dev/sdb2<br />
<br />
Create logical volumes using {{ic|lvcreate --type ''raidlevel''}}, see {{man|7|lvmraid}} and {{man|8|lvcreate}} for more options.<br />
<br />
# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]<br />
<br />
For example:<br />
<br />
# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol MyVolGroup /dev/sda2 /dev/sdb2<br />
<br />
will create a 20 GiB mirrored logical volume named "myraid1vol" in VolGroup00 on {{ic|/dev/sda2}} and {{ic|/dev/sdb2}}.<br />
<br />
== Thin provisioning ==<br />
<br />
{{Note|When mounting a thin LV file system, always remember to use the {{ic|discard}} option or to use [[fstrim]] regularly, to allow the thin LV to shrink as files are deleted.}}<br />
<br />
From {{man|7|lvmthin}}:<br />
<br />
:Blocks in a standard {{man|8|lvm}} Logical Volume (LV) are allocated when the LV is created, but blocks in a thin provisioned LV are allocated as they are written. Because of this, a thin provisioned LV is given a virtual size, and can then be much larger than physically available storage. The amount of physical storage provided for thin provisioned LVs can be increased later as the need arises.<br />
<br />
=== Example: implementing virtual private servers ===<br />
<br />
Here is the classic use case. Suppose you want to start your own VPS service, initially hosting about 100 VPSes on a single PC with a 930 GiB hard drive. Hardly any of the VPSes will actually use all of the storage they are allotted, so rather than allocate 9 GiB to each VPS, you could allow each VPS a maximum of 30 GiB and use thin provisioning to only allocate as much hard drive space to each VPS as they are actually using. Suppose the 930 GiB hard drive is {{ic|/dev/sdb}}. Here is the setup.<br />
<br />
Prepare the volume group, {{ic|MyVolGroup}}.<br />
<br />
# vgcreate MyVolGroup /dev/sdb<br />
<br />
Create the thin pool LV, {{ic|MyThinPool}}. This LV provides the blocks for storage.<br />
<br />
# lvcreate --type thin-pool -n MyThinPool -l 95%FREE MyVolGroup<br />
<br />
The thin pool is composed of two sub-volumes, the data LV and the metadata LV. This command creates both automatically. But the thin pool stops working if either fills completely, and LVM currently does not support the shrinking of either of these volumes. This is why the above command allows for 5% of extra space, in case you ever need to expand the data or metadata sub-volumes of the thin pool.<br />
<br />
For each VPS, create a thin LV. This is the block device exposed to the user for their root partition.<br />
<br />
# lvcreate -n SomeClientsRoot -V 30G --thinpool MyThinPool MyVolGroup<br />
<br />
The block device {{ic|/dev/MyVolGroup/SomeClientsRoot}} may then be used by a [[VirtualBox]] instance as the root partition.<br />
<br />
==== Use thin snapshots to save more space ====<br />
<br />
Thin snapshots are much more powerful than regular snapshots, because they are themselves thin LVs. See Redhat's guide [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index#creating-and-managing-thinly-provisioned-volumes_configuring-and-managing-logical-volumes] for a complete list of advantages thin snapshots have.<br />
<br />
Instead of installing Linux from scratch every time a VPS is created, it is more space-efficient to start with just one thin LV containing a basic installation of Linux:<br />
<br />
# lvcreate -n GenericRoot -V 30G --thinpool MyThinPool MyVolGroup<br />
*** install Linux at /dev/MyVolGroup/GenericRoot ***<br />
<br />
Then create snapshots of it for each VPS:<br />
<br />
# lvcreate -s MyVolGroup/GenericRoot -n SomeClientsRoot<br />
<br />
This way, in the thin pool there is only one copy the data common to all VPSes, at least initially. As an added bonus, the creation of a new VPS is instantaneous.<br />
<br />
Since these are thin snapshots, a write operation to {{ic|GenericRoot}} only causes one COW operation in total, instead of one COW operation per snapshot. This allows you to update {{ic|GenericRoot}} more efficiently than if each VPS were a regular snapshot.<br />
<br />
=== Example: zero-downtime storage upgrade ===<br />
<br />
There are applications of thin provisioning outside of VPS hosting. Here is how you may use it to grow the effective capacity of an already-mounted file system without having to unmount it. Suppose, again, that the server has a single 930 GiB hard drive. The setup is the same as for VPS hosting, only there is only one thin LV and the LV's size is far larger than the thin pool's size.<br />
<br />
# lvcreate -n MyThinLV -V 16T --thinpool MyThinPool MyVolGroup<br />
<br />
This extra virtual space can be filled in with actual storage at a later time by extending the thin pool.<br />
<br />
Suppose some time later, a storage upgrade is needed, and a new hard drive, {{ic|/dev/sdc}}, is plugged into the server. To upgrade the thin pool's capacity, add the new hard drive to the VG:<br />
<br />
# vgextend MyVolGroup /dev/sdc<br />
<br />
Now, extend the thin pool:<br />
<br />
# lvextend -l +95%FREE MyVolGroup/MyThinPool<br />
<br />
Since this thin LV's size is 16 TiB, you could add another 15.09 TiB of hard drive space before finally having to unmount and resize the file system.<br />
<br />
{{Note|You will probably want to use [[Ext4#Reserved_blocks|reserved blocks]] or a [[disk quota]] to prevent applications from attempting to use more physical storage than there actually is.}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== LVM commands do not work ===<br />
<br />
* Load proper module:<br />
<br />
# modprobe dm_mod<br />
<br />
The {{ic|dm_mod}} module should be automatically loaded. In case it does not, you can try:<br />
<br />
{{Accuracy|Should module loading at boot be done using {{ic|/etc/modules-load.d}} instead?}}<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=(dm_mod ...)<br />
}}<br />
<br />
You will need to [[regenerate the initramfs]] to commit any changes you made.<br />
<br />
* Try preceding commands with ''lvm'' like this:<br />
<br />
# lvm pvdisplay<br />
<br />
=== Logical Volumes do not show up ===<br />
<br />
If you are trying to mount existing logical volumes, but they do not show up in {{ic|lvscan}}, you can use the following commands to activate them:<br />
<br />
# vgscan<br />
# vgchange -ay<br />
<br />
=== LVM on removable media ===<br />
<br />
Symptoms:<br />
<br />
{{hc|# vgscan|<br />
Reading all physical volumes. This may take a while...<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error<br />
Found volume group "backupdrive1" using metadata type lvm2<br />
Found volume group "networkdrive" using metadata type lvm2<br />
}}<br />
<br />
Cause: removing an external LVM drive without deactivating the volume group(s) first. Before you disconnect, make sure to:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Fix: assuming you already tried to activate the volume group with {{ic|vgchange -ay ''vg''}}, and are receiving the Input/output errors:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Unplug the external drive and wait a few minutes:<br />
<br />
# vgscan<br />
# vgchange -ay ''volume group name''<br />
<br />
==== Suspend/resume with LVM and removable media ====<br />
<br />
{{Accuracy|Provided solution will not work in more complex setups like LUKS on LVM.|section=LVM on removable media}}<br />
<br />
In order for LVM to work properly with removable media – like an external USB drive – the volume group of the external drive needs to be deactivated before suspend. If this is not done, you may get buffer I/O errors on the dm device (after resume). For this reason, it is not recommended to mix external and internal drives in the same volume group.<br />
<br />
To automatically deactivate the volume groups with external USB drives, tag each volume group with the {{ic|sleep_umount}} tag in this way:<br />
<br />
# vgchange --addtag sleep_umount ''vg_external''<br />
<br />
Once the tag is set, use the following unit file for systemd to properly deactivate the volumes before suspend. On resume, they will be automatically activated by LVM.<br />
<br />
{{hc|/etc/systemd/system/ext_usb_vg_deactivate.service|2=<br />
[Unit]<br />
Description=Deactivate external USB volume groups on suspend<br />
Before=sleep.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=-/etc/systemd/system/deactivate_sleep_vgs.sh<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
and this script:<br />
<br />
{{hc|/etc/systemd/system/deactivate_sleep_vgs.sh|2=<br />
#!/bin/sh<br />
<br />
TAG=@sleep_umount<br />
vgs=$(vgs --noheadings -o vg_name $TAG)<br />
<br />
echo "Deactivating volume groups with $TAG tag: $vgs"<br />
<br />
# Unmount logical volumes belonging to all the volume groups with tag $TAG<br />
for vg in $vgs; do<br />
for lv_dev_path in $(lvs --noheadings -o lv_path -S lv_active=active,vg_name=$vg); do<br />
echo "Unmounting logical volume $lv_dev_path"<br />
umount $lv_dev_path<br />
done<br />
done<br />
<br />
# Deactivate volume groups tagged with sleep_umount<br />
for vg in $vgs; do<br />
echo "Deactivating volume group $vg"<br />
vgchange -an $vg<br />
done<br />
}}<br />
<br />
Finally, [[enable]] the unit.<br />
<br />
=== Resizing a contiguous logical volume fails ===<br />
<br />
If trying to extend a logical volume errors with:<br />
<br />
" Insufficient suitable contiguous allocatable extents for logical volume "<br />
<br />
The reason is that the logical volume was created with an explicit contiguous allocation policy (options {{ic|-C y}} or {{ic|--alloc contiguous}}) and no further adjacent contiguous extents are available.[https://hostatic.ro/lvm-inherit-and-contiguous-policies/]<br />
<br />
To fix this, prior to extending the logical volume, change its allocation policy with {{ic|lvchange --alloc inherit ''logical_volume''}}. If you need to keep the contiguous allocation policy, an alternative approach is to move the volume to a disk area with sufficient free extents. See [https://superuser.com/questions/435075/how-to-align-logical-volumes-on-contiguous-physical-extents].<br />
<br />
=== Command "grub-mkconfig" reports "unknown filesystem" errors ===<br />
<br />
Make sure to remove snapshot volumes before [[GRUB#Generate the main configuration file|generating grub.cfg]].<br />
<br />
=== Thinly-provisioned root volume device times out ===<br />
<br />
With a large number of snapshots, {{ic|thin_check}} runs for a long enough time so that waiting for the root device times out. To compensate, add the {{ic|1=rootdelay=60}} kernel boot parameter to your boot loader configuration. Or, make {{ic|thin_check}} skip checking block mappings (see [https://www.redhat.com/archives/linux-lvm/2016-January/msg00010.html]) and [[regenerate the initramfs]]:<br />
<br />
{{hc|/etc/lvm/lvm.conf|<br />
2=thin_check_options = [ "-q", "--clear-needs-check-flag", "--skip-mappings" ]<br />
}}<br />
<br />
=== Delay on shutdown ===<br />
<br />
If you use RAID, snapshots or thin provisioning and experience a delay on shutdown, make sure {{ic|lvm2-monitor.service}} is [[started]]. See {{Bug|50420}}.<br />
<br />
=== Hibernating into a thinly-provisioned swap volume ===<br />
<br />
See [[Power management/Suspend and hibernate#Hibernation into a thinly-provisioned LVM volume]].<br />
<br />
== See also ==<br />
<br />
* [https://sourceware.org/lvm2/ LVM2 Resource Page] on SourceWare.org<br />
* [[Gentoo:LVM]]<br />
* [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index Red Hat Enterprise 9: Configuring and managing logical volumes]<br />
* [https://www.tutonics.com/2012/11/ubuntu-lvm-guide-part-1.html Ubuntu LVM Guide Part 1][https://www.tutonics.com/2012/12/lvm-guide-part-2-snapshots.html Part 2 details snapshots]</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=743673Talk:Unified Extensible Firmware Interface/Secure Boot2022-08-28T12:42:38Z<p>DasMenschy: /* Section "Shim with key and GRUB" */ new section</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
:I personally had many more digits, but that's because the <code>SecureBoot*</code> glob matches a <code>SecureBootSetup-...</code> file. If I use <code>SecureBoot-*</code> (note the dash), I get the expected output (secure boot is disabled on my system):<br />
<nowiki>od -An -tu1 /sys/firmware/efi/efivars/SecureBoot-*<br />
6 0 0 0 0</nowiki><br />
:--[[User:PsYchotic|PsYchotic]] ([[User talk:PsYchotic|talk]]) 18:53, 1 June 2022 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
:::Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.<br />
:::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).<br />
:::About the {{ic|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.<br />
:::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?<br />
:::[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 02:17, 22 December 2021 (UTC)<br />
<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
: The current warning isn't much help in finding out if one's device is going to be affected. Is [https://github.com/Foxboron/sbctl/wiki/FAQ this] reliable enough to be added to the wiki as a possible check ? --[[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 21:44, 30 December 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)<br />
:: There isn't any easy tools for doing any of this which is why I started writing [https://github.com/Foxboron/sbctl sbctl]]. However I'm not super comfortable adding it to Arch Wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 19:44, 2 January 2022 (UTC)<br />
:::: 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.<br />
:::: [[User:Kiasoc5|Kiasoc5]] ([[User talk:Kiasoc5|talk]]) 19:16, 16 May 2022 (UTC)<br />
<br />
== about restoring OEM keys ==<br />
This is a little off-topic, but:<br />
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<br />
<br />
{{unsigned|14:12, 5 August 2022|Solstice}}<br />
: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? <br />
:* Option 1: At the end of section [[Secure Boot#Using your own keys|"3.1 Using your own keys"]], just after [[Secure Boot#Dual booting with other operating systems|"3.1.7 Dual booting with other operating systems"]], a section: '''"3.1.8 Restoring the OEM Secure Boot variables"'''?<br />
:* Option 2: Or included in the section [[Secure Boot#Backing up current variables|"3.1.2 Backing up current variables"]]? <br />
:[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:27, 5 August 2022 (UTC)<br />
<br />
== Section "Shim with key and GRUB" ==<br />
<br />
Concerning the section [[Unified Extensible Firmware Interface/Secure Boot#Shim with key and GRUB]]: <br />
<br />
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 [https://www.linux.org/threads/understanding-the-various-grub-modules.11142/ this thread on linux.org], which doesn't have all modules however and is already outdated. <br />
The [https://www.gnu.org/software/grub/manual/grub/grub.html official GNU GRUB manual] has '''no documentation at all''' about the modules. <br />
<br />
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?<br />
<br />
Thank you in advance for help! <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 12:42, 28 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=User_talk:Erus_Iluvatar&diff=743672User talk:Erus Iluvatar2022-08-28T12:30:40Z<p>DasMenschy: /* Unified Extensible Firmware Interface/Secure Boot */ fix link</p>
<hr />
<div>== Thank you ==<br />
<br />
Thank you for your recent edit on [[Pipewire]]. I am new to ArchWiki and missed the correct formatting. Thanks for fixing it. Cheers! [[User:Darksaber|Darksaber]] ([[User talk:Darksaber|talk]])<br />
<br />
: Don't worry, everyone has to start somewhere ;). If you want to read before future contributions, look at [[ArchWiki:Contributing#Resources]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 13:23, 11 March 2022 (UTC)<br />
<br />
== Minor edit mark ==<br />
<br />
Thank you for your contributions to the wiki. Please mark your edits as [[Wikipedia:Wikipedia:Minor edit|minor]] when necessary, so readers can filter them with "non-minor edits" filter. Thank you. -- [[User:Thmeiov|Thmeiov]] ([[User talk:Thmeiov|talk]]) 12:17, 14 March 2022 (UTC)<br />
<br />
: You're right, I should be more careful on this. Thank you for reminding me ! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:30, 14 March 2022 (UTC)<br />
<br />
== Thanks for the edits on the Virt-Manager page ==<br />
Thanks for the recent edits you made im pretty new to ArchWiki/MediaWiki and suck formatting so thanks for fixing my bad formating <br />
[[User:ShinobuNarusaka|ShinobuNarusaka]] ([[User talk:ShinobuNarusaka|talk]])<br />
<br />
: Hi ! Thank you for contributing a new page on a subject you're comfortable with. Don't worry, practice makes perfect. To double check your content before future contributions, look at [[ArchWiki:Contributing#Resources]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 05:56, 27 March 2022 (UTC)<br />
<br />
== $include Readline question ==<br />
Hi, thanks for your work. I've seen that you have added a space in [[Readline#History]]. `man bash` (and some blogs) have no space in "$include /etc/inputrc". Do you have any reference? --[[User:Marzal|Marzal]] ([[User talk:Marzal|talk]]) 22:19, 14 April 2022 (UTC)<br />
<br />
: Hi, thanks for pointing out my mistake: I had read the section too quickly and concluded this line was missing a space between the prompt and the command, but this is not the case. I've reverted my edit, sorry for the confusion. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 03:43, 15 April 2022 (UTC)<br />
<br />
== Thanks for improving the edit ==<br />
<br />
Thanks for correcting the info, and naming it the 5000 series rather than Ryzen 9 or 5. AMD Ryzen series are even more ambiguous than Intel. AMD Ryzen 5xxx series processor could be Ryzen 5(5600x), Ryzen 9(5950x), or Ryzen 7(5800x). Currently using Ryzen 9 5950x and Ryzen 9 5900x on two of my desktops, on Windows they consume 100 watts less power and my current linux setup, so was looking into that article and was thinking of making the switch from Pop OS to Arch Linux.<br />
{{Unsigned|2022-06-17T04:56:21|Gagan0123}}<br />
<br />
: Hi! I saw the ambiguousness of the existing wording when finishing to revert your edit, so instead of having more people tripping on it I tried to make it better :)<br />
: Good luck on your journey ! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 05:28, 17 June 2022 (UTC)<br />
<br />
== Signature is unknown trust ==<br />
<br />
Thanks for the edits! They made it easier to find the solution. --[[User:Topcat01|Topcat01]] ([[User talk:Topcat01|talk]])<br />
<br />
: Credit where credit is due: [[User:Lahwaacz]] did 99.99% of the work, I've only fixed a capitalization issue. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 20:26, 29 July 2022 (UTC)<br />
<br />
== <s>Regarding zswap and zram</s> ==<br />
<br />
Greetings.<br />
<br />
Don't you think it would be better if we move the line "'''This increases the performance and decreases the I/O operations'''" in the swap article to make it clearer that both zswap and zram get those benefits? The current formatting makes it seem like those benefits only apply to zswap.<br />
<br />
Also, should a short paragraph be added in [[Improving_performance#zram_or_zswap]] to imply that zram might be preferable over zswap when using an HDD? Since that page is dedicated to performance, it would make sense to add a tip or some sort because while it is true that zswap helps a lot with disk swap performance degradation, it's still not fully gone. The lower the disk activity is on HDDs, the more performant and responsive the system is going to be. Thus since using zram requires no swap on disk, that might be a better recommendation (unless you disagree with this).<br />
{{Unsigned|2022-08-21T17:49:29|Cont999}}<br />
<br />
:Hi! Rewording the sentence to avoid it being ambiguous is completely fine by me. <br />
: Regarding the benefit of zram over zswap, there is a great writeup in two parts ([https://haydenjames.io/linux-performance-almost-always-add-swap-space/] and [https://haydenjames.io/linux-performance-almost-always-add-swap-part2-zram/]) which concludes as follows: <br />
::[…]swap also provides some benefits to overall system stability and performance. The kernel was designed to work with swap. With that said, your specific setup or requirements may work best without swap or ZRAM. Red Hat puts it nicely:<br />
::“Systems without swap can make sense and are supported by Red Hat – just be sure the behavior of such a system under memory pressure is what you want. In most environments, a bit of swap makes sense. Without swap, the system will call the OOM when the memory is exhausted. [Make sure to] …prioritize which processes get killed first in configuring oom_adj_score.”<br />
:zswap has not performance penalty over zram, since (quoting the intro of [[zswap]]): <br />
::Once the pool is full or the RAM is exhausted, the least recently used (LRU) page is decompressed and written to disk, as if it had not been intercepted. After the page has been decompressed into the swap cache, the compressed version in the pool can be freed. <br />
:A quick search gives a [https://unix.stackexchange.com/a/407134 stackexchange answer] with benchmarks on the subject with the conclusion being either solution is good at avoiding disk writes. <br />
:I'd be happy to see benchmarks demonstrating the superiority of a solution over the other, it would be a great addition to the page. <br />
:In the meantime, expanding on the simplicity of zram (no need for swap, less configuration option) as a way of promoting it seems fine to me. <br />
: --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 18:11, 21 August 2022 (UTC)<br />
<br />
::Looks like the last ambiguous reference [[Special:Diff/743372|in the swap page]] has been reworked. I've not heard back from you, I guess this is closed? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:13, 27 August 2022 (UTC)<br />
<br />
== <s>/var partition and NVIDIA</s> ==<br />
<br />
I really think we should also mention that adding the amount of video memory to /var partition when using the /var/tmp path under it to store NVIDIA VRAM on hibernate/suspend might be necessary. The current size recommendation (8-12GiB) didn't consider that NVIDIA would use the partition to store its video memory contents, thus this size is maybe not be sufficient. What do you think?<br />
[[User:Cont999|Cont999]] ([[User talk:Cont999|talk]]) 04:32, 27 August 2022 (UTC)<br />
<br />
:I've tried to be explicit about the relationship between video memory amount for the affected users and this partition, but it's probably not clear enough, [[Special:Diff/743446|how about now]]? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:28, 27 August 2022 (UTC)<br />
<br />
:: That seems good enough. Sweet! Thank you. [[User:Cont999|Cont999]] ([[User talk:Cont999|talk]]) 16:29, 27 August 2022 (UTC)<br />
<br />
::: Excellent :) And thank ''you'' for your contributions! Closing. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 18:53, 27 August 2022 (UTC)<br />
<br />
== [[Unified Extensible Firmware Interface/Secure Boot]] ==<br />
<br />
Hi Erus Iluvatar, thank you for improving my contributions to the [[Unified Extensible Firmware Interface/Secure Boot]] article! Especially the formatting. <br />
<br />
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 [https://www.linux.org/threads/understanding-the-various-grub-modules.11142/ this thread on linux.org], which doesn't have all modules however and is already outdated. <br />
The [https://www.gnu.org/software/grub/manual/grub/grub.html official GNU GRUB manual] has '''no documentation at all''' about the modules. <br />
<br />
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?<br />
<br />
Thank you in advance for an answer! <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 12:30, 28 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=User_talk:Erus_Iluvatar&diff=743670User talk:Erus Iluvatar2022-08-28T12:05:10Z<p>DasMenschy: /* Unified Extensible Firmware Interface/Secure Boot */ new section</p>
<hr />
<div>== Thank you ==<br />
<br />
Thank you for your recent edit on [[Pipewire]]. I am new to ArchWiki and missed the correct formatting. Thanks for fixing it. Cheers! [[User:Darksaber|Darksaber]] ([[User talk:Darksaber|talk]])<br />
<br />
: Don't worry, everyone has to start somewhere ;). If you want to read before future contributions, look at [[ArchWiki:Contributing#Resources]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 13:23, 11 March 2022 (UTC)<br />
<br />
== Minor edit mark ==<br />
<br />
Thank you for your contributions to the wiki. Please mark your edits as [[Wikipedia:Wikipedia:Minor edit|minor]] when necessary, so readers can filter them with "non-minor edits" filter. Thank you. -- [[User:Thmeiov|Thmeiov]] ([[User talk:Thmeiov|talk]]) 12:17, 14 March 2022 (UTC)<br />
<br />
: You're right, I should be more careful on this. Thank you for reminding me ! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 12:30, 14 March 2022 (UTC)<br />
<br />
== Thanks for the edits on the Virt-Manager page ==<br />
Thanks for the recent edits you made im pretty new to ArchWiki/MediaWiki and suck formatting so thanks for fixing my bad formating <br />
[[User:ShinobuNarusaka|ShinobuNarusaka]] ([[User talk:ShinobuNarusaka|talk]])<br />
<br />
: Hi ! Thank you for contributing a new page on a subject you're comfortable with. Don't worry, practice makes perfect. To double check your content before future contributions, look at [[ArchWiki:Contributing#Resources]]. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 05:56, 27 March 2022 (UTC)<br />
<br />
== $include Readline question ==<br />
Hi, thanks for your work. I've seen that you have added a space in [[Readline#History]]. `man bash` (and some blogs) have no space in "$include /etc/inputrc". Do you have any reference? --[[User:Marzal|Marzal]] ([[User talk:Marzal|talk]]) 22:19, 14 April 2022 (UTC)<br />
<br />
: Hi, thanks for pointing out my mistake: I had read the section too quickly and concluded this line was missing a space between the prompt and the command, but this is not the case. I've reverted my edit, sorry for the confusion. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 03:43, 15 April 2022 (UTC)<br />
<br />
== Thanks for improving the edit ==<br />
<br />
Thanks for correcting the info, and naming it the 5000 series rather than Ryzen 9 or 5. AMD Ryzen series are even more ambiguous than Intel. AMD Ryzen 5xxx series processor could be Ryzen 5(5600x), Ryzen 9(5950x), or Ryzen 7(5800x). Currently using Ryzen 9 5950x and Ryzen 9 5900x on two of my desktops, on Windows they consume 100 watts less power and my current linux setup, so was looking into that article and was thinking of making the switch from Pop OS to Arch Linux.<br />
{{Unsigned|2022-06-17T04:56:21|Gagan0123}}<br />
<br />
: Hi! I saw the ambiguousness of the existing wording when finishing to revert your edit, so instead of having more people tripping on it I tried to make it better :)<br />
: Good luck on your journey ! --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 05:28, 17 June 2022 (UTC)<br />
<br />
== Signature is unknown trust ==<br />
<br />
Thanks for the edits! They made it easier to find the solution. --[[User:Topcat01|Topcat01]] ([[User talk:Topcat01|talk]])<br />
<br />
: Credit where credit is due: [[User:Lahwaacz]] did 99.99% of the work, I've only fixed a capitalization issue. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 20:26, 29 July 2022 (UTC)<br />
<br />
== <s>Regarding zswap and zram</s> ==<br />
<br />
Greetings.<br />
<br />
Don't you think it would be better if we move the line "'''This increases the performance and decreases the I/O operations'''" in the swap article to make it clearer that both zswap and zram get those benefits? The current formatting makes it seem like those benefits only apply to zswap.<br />
<br />
Also, should a short paragraph be added in [[Improving_performance#zram_or_zswap]] to imply that zram might be preferable over zswap when using an HDD? Since that page is dedicated to performance, it would make sense to add a tip or some sort because while it is true that zswap helps a lot with disk swap performance degradation, it's still not fully gone. The lower the disk activity is on HDDs, the more performant and responsive the system is going to be. Thus since using zram requires no swap on disk, that might be a better recommendation (unless you disagree with this).<br />
{{Unsigned|2022-08-21T17:49:29|Cont999}}<br />
<br />
:Hi! Rewording the sentence to avoid it being ambiguous is completely fine by me. <br />
: Regarding the benefit of zram over zswap, there is a great writeup in two parts ([https://haydenjames.io/linux-performance-almost-always-add-swap-space/] and [https://haydenjames.io/linux-performance-almost-always-add-swap-part2-zram/]) which concludes as follows: <br />
::[…]swap also provides some benefits to overall system stability and performance. The kernel was designed to work with swap. With that said, your specific setup or requirements may work best without swap or ZRAM. Red Hat puts it nicely:<br />
::“Systems without swap can make sense and are supported by Red Hat – just be sure the behavior of such a system under memory pressure is what you want. In most environments, a bit of swap makes sense. Without swap, the system will call the OOM when the memory is exhausted. [Make sure to] …prioritize which processes get killed first in configuring oom_adj_score.”<br />
:zswap has not performance penalty over zram, since (quoting the intro of [[zswap]]): <br />
::Once the pool is full or the RAM is exhausted, the least recently used (LRU) page is decompressed and written to disk, as if it had not been intercepted. After the page has been decompressed into the swap cache, the compressed version in the pool can be freed. <br />
:A quick search gives a [https://unix.stackexchange.com/a/407134 stackexchange answer] with benchmarks on the subject with the conclusion being either solution is good at avoiding disk writes. <br />
:I'd be happy to see benchmarks demonstrating the superiority of a solution over the other, it would be a great addition to the page. <br />
:In the meantime, expanding on the simplicity of zram (no need for swap, less configuration option) as a way of promoting it seems fine to me. <br />
: --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 18:11, 21 August 2022 (UTC)<br />
<br />
::Looks like the last ambiguous reference [[Special:Diff/743372|in the swap page]] has been reworked. I've not heard back from you, I guess this is closed? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:13, 27 August 2022 (UTC)<br />
<br />
== <s>/var partition and NVIDIA</s> ==<br />
<br />
I really think we should also mention that adding the amount of video memory to /var partition when using the /var/tmp path under it to store NVIDIA VRAM on hibernate/suspend might be necessary. The current size recommendation (8-12GiB) didn't consider that NVIDIA would use the partition to store its video memory contents, thus this size is maybe not be sufficient. What do you think?<br />
[[User:Cont999|Cont999]] ([[User talk:Cont999|talk]]) 04:32, 27 August 2022 (UTC)<br />
<br />
:I've tried to be explicit about the relationship between video memory amount for the affected users and this partition, but it's probably not clear enough, [[Special:Diff/743446|how about now]]? --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:28, 27 August 2022 (UTC)<br />
<br />
:: That seems good enough. Sweet! Thank you. [[User:Cont999|Cont999]] ([[User talk:Cont999|talk]]) 16:29, 27 August 2022 (UTC)<br />
<br />
::: Excellent :) And thank ''you'' for your contributions! Closing. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 18:53, 27 August 2022 (UTC)<br />
<br />
== [[Unified Extensible Firmware Interface/Secure Boot]] ==<br />
<br />
Hi Erus Iluvatar, thank you for improving my contributions to the [[Unified Extensible Firmware Interface/Secure Boot]] article! Especially the formatting. <br />
<br />
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 [https://www.linux.org/threads/understanding-the-various-grub-modules.11142/ this thread on linux.org], which doesn't have all modules however and is already outdated. <br />
The [https://www.gnu.org/software/grub/manual/grub/grub.html#chainloader official GNU GRUB manual] has '''no documentation at all''' about the modules. <br />
<br />
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?<br />
<br />
Thank you in advance for an answer! <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 12:05, 28 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=743596Unified Extensible Firmware Interface/Secure Boot2022-08-27T22:01:55Z<p>DasMenschy: /* Shim with key and GRUB */ Add list of GRUB modules that are used by Ubuntu</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Security}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Unified_Extensible_Firmware_Interface#Secure_boot|Secure Boot]] is a security feature found in the [[UEFI]] standard, designed to add a layer of protection to the [[Arch boot process|pre-boot process]]: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.<br />
<br />
As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|cover]], while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and [[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|cons]].<br />
<br />
{{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article and [[#See also|other online resources]]. This article focuses on how to set up Secure Boot in Arch Linux.}}<br />
<br />
== Checking Secure Boot status ==<br />
<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 />
<br />
An easy way to check Secure Boot status on systems using [[systemd]] is to use [[systemd-boot]]:<br />
<br />
{{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}}<br />
<br />
{{bc|$ bootctl status<br />
System:<br />
Firmware: UEFI 2.70 (American Megatrends 5.15)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
Boot into FW: supported<br />
...<br />
}}<br />
<br />
Here we see that Secure Boot is enabled and enforced; other values are {{ic|disabled}} for Secure Boot and {{ic|setup}} for Setup Mode[https://github.com/systemd/systemd/issues/8154#issue-296106251].<br />
<br />
{{Accuracy|This command might display more than five digits even though secure boot is enabled.}}<br />
<br />
Another way to check whether the machine was booted with Secure Boot is to use this command:<br />
<br />
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<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 />
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:<br />
<br />
{{hc|# dmesg {{!}} grep -i secure|<br />
[ 0.013442] Secure boot disabled<br />
[ 0.013442] Secure boot could not be determined<br />
}}<br />
<br />
The kernel messages will otherwise read {{ic|Secure boot enabled}}.<br />
<br />
== Booting an installation medium ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disabling Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.<br />
<br />
[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] images provide a way to use secure boot on installation media.<br />
<br />
=== Disabling 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 [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
=== Remastering the installation image ===<br />
<br />
{{Expansion|Add explicit instructions.}}<br />
<br />
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. Another option would be to borrow the {{ic|BOOTx64.EFI}} (shim) and {{ic|grubx64.efi}} from installation media of another GNU+Linux distribution that supports Secure Boot and modify the GRUB configuration to one's needs. In this case, the authentication chain of Secure Boot in said distribution's installation media should end to the {{ic|grubx64.efi}} ( [https://www.linux-magazine.com/index.php/layout/set/print/Issues/2014/164/The-State-of-Secure-Boot/(tagid)/154 for example Ubuntu]) so that GRUB would boot the unsigned kernel and initramfs from archiso. 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 />
== Implementing Secure Boot ==<br />
<br />
There are certain conditions making for an ideal setup of ''Secure boot'':<br />
<br />
# UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]]<br />
# Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/]<br />
# UEFI directly loads a user-signed [[EFISTUB]] combined kernel image (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface<br />
# Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.<br />
# Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement.<br />
<br />
A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party.<br />
<br />
=== Using your own keys ===<br />
<br />
{{Warning|Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware ([[Wikipedia:OpROM|OpROMs]]), that get executed during boot, [[#Microsoft Windows|are signed using Microsoft 3rd Party UEFI CA certificate]].}}<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 denylisted 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 />
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 />
==== Install efitools ====<br />
<br />
Nearly all of the following sections require you to [[install]] the {{Pkg|efitools}} package.<br />
<br />
==== Backing up current variables ====<br />
<br />
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error.<br />
<br />
Run the following commands to backup all four of the principal Secure Boot variables:<br />
<br />
$ efi-readvar -v PK -o old_PK.esl<br />
$ efi-readvar -v KEK -o old_KEK.esl<br />
$ efi-readvar -v db -o old_db.esl<br />
$ efi-readvar -v dbx -o old_dbx.esl<br />
<br />
If you perform these commands on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft.<br />
<br />
==== Creating keys ====<br />
<br />
===== Manual process =====<br />
<br />
To generate keys, perform the following steps.<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 {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware.<br />
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and 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 />
===== Helper scripts =====<br />
<br />
A helper/convenience script is offered by the author of the reference page on this topic[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys] (requires [[python]]). A mildly edited version is also packaged as {{AUR|sbkeys}}.<br />
<br />
In order to use it, simply create a folder in a secure location (e.g. {{ic|/etc/efi-keys/}} if later use of {{AUR|sbupdate-git}} to automate unified kernel image creation and signing is planned) and run it:<br />
<br />
# mkdir /etc/efi-keys<br />
# cd !$<br />
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh<br />
# chmod +x mkkeys.sh<br />
# ./mkkeys.sh<br />
''Enter a Common Name to embed in the keys, e.g. "Secure Boot"''<br />
<br />
This will produce the required files in different formats.<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, [[#Enrolling keys in firmware|enroll it]].<br />
<br />
==== Signing EFI binaries ====<br />
<br />
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched.<br />
<br />
===== Manually with sbsigntools =====<br />
<br />
Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}.<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* 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 />
<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 />
To sign your kernel and boot manager use ''sbsign'', e.g.:<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 />
{{Warning|Signing kernel only will not protect the initramfs from tampering. See [[Unified kernel image]] to know how to produce a combined image that you can then manually sign with ''sbsign''.}}<br />
<br />
===== Signing the kernel with a pacman hook =====<br />
<br />
You can also use mkinitcpio's [[pacman hook]] to sign the kernel on install and updates.<br />
<br />
Copy {{ic|/usr/share/libalpm/hooks/90-mkinitcpio-install.hook}} to {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}} and {{ic|/usr/share/libalpm/scripts/mkinitcpio-install}} to {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}.<br />
<br />
In {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}}, replace:<br />
<br />
Exec = /usr/share/libalpm/scripts/mkinitcpio-install<br />
<br />
with:<br />
<br />
Exec = /usr/local/share/libalpm/scripts/mkinitcpio-install<br />
<br />
In {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}, replace:<br />
<br />
install -Dm644 "${line}" "/boot/vmlinuz-${pkgbase}"<br />
<br />
with:<br />
<br />
sbsign --key ''/path/to/''db.key --cert ''/path/to/''db.crt --output "/boot/vmlinuz-${pkgbase}" "${line}"<br />
<br />
If you are using systemd-boot, there is a [[Systemd-boot#Automatic update|dedicated pacman hook]] doing this task semi-automatically.<br />
<br />
===== Fully automated unified kernel generation and signing with sbupdate =====<br />
<br />
[https://github.com/andreyv/sbupdate sbupdate] is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through [[pacman hooks]].<br />
<br />
Install {{AUR|sbupdate-git}} and configure it following the instructions given on the project's homepage.[https://github.com/andreyv/sbupdate#sbupdate]<br />
<br />
{{Tip|If using [[systemd-boot]], set {{ic|1=OUT_DIR="EFI/Linux"}} to get your signed kernel images directly recognized without needing configuration. See {{man|7|systemd-boot|FILES}} and [[Systemd-boot#Adding loaders]].}}<br />
<br />
Once configured, simply run {{ic|sbupdate}} as root for first-time image generation.<br />
<br />
{{Note|''sbupdate'' output often contains errors such as {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}}. Those are harmless and can be safely ignored.[https://github.com/andreyv/sbupdate/issues/30]}}<br />
<br />
==== Putting 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 />
==== Enrolling keys in firmware ====<br />
<br />
Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
{{Tip|As the '''dbx''' (forbidden signatures db) is empty, it can be safely left out in the following instructions.}}<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 sbkeysync =====<br />
<br />
Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure -<br />
<br />
/etc/secureboot/keys<br />
├── db<br />
├── dbx<br />
├── KEK<br />
└── PK<br />
<br />
For example using:<br />
<br />
# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}<br />
<br />
Then copy each of the ''.auth'' files that were generated earlier into their respective locations (for example, {{ic|PK.auth}} into {{ic|/etc/secureboot/keys/PK}} and so on).<br />
<br />
If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use:<br />
<br />
# sbkeysync --pk --dry-run --verbose<br />
<br />
Finally, use {{ic|sbkeysync}} to enroll your keys.<br />
<br />
# sbkeysync --verbose<br />
# sbkeysync --verbose --pk<br />
<br />
{{Tip|<br />
* If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}.<br />
* If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}.<br />
}}<br />
<br />
On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy.<br />
<br />
===== Using firmware setup utility =====<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files '''EXCEPT OF {{ic|noPK.auth}}''' files to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
{{Warning|'''Do not copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC!''' If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with his or her own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a safe place where only you have access to. A safe place for the noPK.auth file are:<br />
<br />
* an '''external USB stick with an [[EFI system partition]]''' when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage.<br />
* [[Data-at-rest encryption|encrypted storage on your PC]] when using {{ic|sbkeysync}}.<br />
The [[EFI system partition]] of your PC must not be encrypted according to the UEFI specifications and can be mounted and read on another PC (if your PC is stolen and if the hard drive is taken out and connected to another PC). Copying the {{ic|noPK.auth}} file to the ESP of your PC and deleting it afterwards is also not advisable, because deleted files on the FAT32 [[EFI system partition]] [[File recovery#TestDisk and PhotoRec|can be recovered with tools like PhotoRec]].<br />
}}<br />
<br />
Launch firmware setup utility and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
Firmwares have various different interfaces, see [https://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 />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<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 [https://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]]?|section=Booting Windows with custom bootloader signature}}<br />
<br />
It is usually '''not''' possible to boot Windows by signing its bootloader ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) with a [[#Creating keys|custom, personal key]] with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables:<br />
<br />
* if {{ic|bootmgfw.efi}} contains a signature '''both''' from the "Microsoft Windows Production PCA 2011" '''and''' from your own Secure Boot DB key (so '''two signatures'''), then UEFI firmware implementations like ''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' will not launch {{ic|bootmgfw.efi}} and will throw a security violation error ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}'''): UEFI firmware implementation like this can probably only read the '''first''' signature - not the '''second''' one. Only the certificate for the second signature is enrolled in the UEFI Secure Boot variables, so the Secure Boot verification fails.<br />
* if the "Microsoft Windows Production PCA 2011" signature from the {{ic|bootmgfw.efi}} file is stripped/removed, and only a signature from your own Secure Boot DB key is added to the file, then UEFI will launch the file - but Windows will launch a recovery/repair environment: Windows complains that the Windows installation is broken (because the "Microsoft Windows Production PCA 2011" signature on {{ic|bootmgfw.efi}} file is missing).<br />
<br />
So to [[dual boot with Windows]],<br />
<br />
* you either have to add the hash of {{ic|bootmgfw.efi}} to the list of allowed hashes in the {{ic|DB}} variable; and you have to update the {{ic|DB}} variable every time a Windows Update changes {{ic|bootmgfw.efi}}. This is very tedious, error-prone and not supported by Microsoft; and for example Bitlocker will not work properly anymore with this setup (Bitlocker will ask for your recovery password every time to decrypt your Windows partition).<br />
* or you have to add Microsoft's certificates to the UEFI Secure Boot variables [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has two {{ic|DB}} certificates and one {{ic|KEK}} certificate]:<br />
** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 certificate] must be included in the {{ic|DB}} variable in order to allow the Windows Operating System to load.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 certificate] aka the Microsoft 3rd Party UEFI CA certificate should be included in the {{ic|DB}} variable in order to use third-party binaries like UEFI drivers, option ROMs, {{Pkg|shim}}, etc.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 certificate] should be included in the {{ic|KEK}} variable, in order to "enable revocation of bad images by updating the {{ic|DBX}} and potentially for updating {{ic|DB}} to prepare for newer Windows signed images". However, Windows will also boot without the "Microsoft Corporation KEK CA 2011" certificate.<br />
<br />
Create EFI Signature Lists from Microsoft's DER format {{ic|DB}} certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt<br />
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl<br />
<br />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format {{ic|KEK}} certificate using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}):<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK.esl MicCorKEKCA2011_2011-06-24.crt<br />
<br />
Sign a {{ic|DB}} variable update with your {{ic|KEK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|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 />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Sign a {{ic|KEK}} variable update with your {{ic|PK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|KEK}} certificate:<br />
<br />
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth<br />
<br />
Follow [[#Enrolling keys in firmware]] to enroll {{ic|add_MS_db.auth}} and for strict conformity with Microsoft UEFI Secure Boot requirements {{ic|add_MS_Win_KEK.auth}} into the UEFI Secure Boot Database variables.<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 an allowlist called Machine Owner Key list, abbreviated MokList. 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 />
{{Warning|What Microsoft calls "Secured-core PCs" do not ship with Microsoft 3rd Party UEFI CA certificate (Microsoft Corporation UEFI CA 2011) enrolled.[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot]. The only enrolled DB certificate is the Microsoft Windows Production PCA 2011 certificate which is exclusively used to sign the Windows boot loader.<br />
<br />
The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate.<br />
}}<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 [[#Disabling Secure Boot]].}}<br />
<br />
===== Delete enrolled hash =====<br />
<br />
Every entry of hashes enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hashes to free the space and to prevent outdated programs from booting.<br />
<br />
[[Install]] {{Pkg|efitools}} and copy {{ic|KeyTool.efi}}:<br />
<br />
# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi<br />
<br />
Manage to boot to Preloader and you will see the KeyTool entry. You can then edit hashes in the MOK database.<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|<br />
* 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 />
* Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details.<br />
* It might be worth mentioning that if you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with {{ic|mokutil --disable-validation}}. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows with {{ic|chainloader}} in grub.<br />
}}<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 />
{{Note|<br />
* Make sure you do NOT copy fbx64.efi (which is under the same directory) unless you actually have a valid bootx64.csv to use. Otherwise shim will NOT execute grubx64.efi but will appear to fail to work and just reset the machine.<br />
}}<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 />
Finally, create a new NVRAM entry to boot {{ic|BOOTx64.EFI}}:<br />
<br />
# efibootmgr --verbose --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI<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 />
Target = linux-lts<br />
Target = linux-hardened<br />
Target = linux-zen<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 />
====== Shim with key and GRUB ======<br />
<br />
'''GRUB can only be booted in Secure Boot mode if all necessary modules are included in its EFI binary.''' Since GRUB version {{ic|2.06.r261.g2f4430cc0}}, sideloading in Secure Boot Mode via '''{{ic|insmod}}''' is '''no longer allowed'''. If the GRUB modules are not embedded in the EFI binary, and GRUB tries to sideload/{{ic|insmod}} them, GRUB will '''fail''' to boot with the message '''{{ic|error: prohibited by secure boot policy}}'''.<br />
<br />
That's why the GRUB EFI binary has to be rebuilt with the modules and signed. <br />
GRUB can only boot the Linux Kernel and initramfs if it has all the necessary modules included in its EFI binary to read/decrypt/access the disk or partition on which the Linux Kernel and initramfs are located. <br />
<br />
Ubuntu, according to '''[https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=ubuntu#n87 its official build script]''', embeds the following GRUB modules in its signed GRUB EFI binary {{ic|grubx64.efi}}: <br />
<br />
'''1. the "basic" modules, necessary for booting from a CD or from a simple-partitioned disk, see [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=ubuntu#n87 line 87 in its build script]:''' <br />
CD_MODULES="<br />
all_video<br />
boot<br />
btrfs<br />
cat<br />
chain<br />
configfile<br />
echo<br />
efifwsetup<br />
efinet<br />
ext2<br />
fat<br />
font<br />
gettext<br />
gfxmenu<br />
gfxterm<br />
gfxterm_background<br />
gzio<br />
halt<br />
help<br />
hfsplus<br />
iso9660<br />
jpeg<br />
keystatus<br />
loadenv<br />
loopback<br />
linux<br />
ls<br />
lsefi<br />
lsefimmap<br />
lsefisystab<br />
lssal<br />
memdisk<br />
minicmd<br />
normal<br />
ntfs<br />
part_apple<br />
part_msdos<br />
part_gpt<br />
password_pbkdf2<br />
png<br />
probe<br />
reboot<br />
regexp<br />
search<br />
search_fs_uuid<br />
search_fs_file<br />
search_label<br />
sleep<br />
smbios<br />
squash4<br />
test<br />
true<br />
video<br />
xfs<br />
zfs<br />
zfscrypt<br />
zfsinfo<br />
"<br />
<br />
'''2. the "platform-specific" modules for x86_64-efi architecture, see [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=ubuntu#n147 line 147 in its script], necessary for e.g.:''' <br />
* playing sounds during boot: {{ic|play}}<br />
* identifying the CPU at boot: {{ic|cpuid}} <br />
* UEFI booting: {{ic|linuxefi}} and <br />
* Measured Boot / [[TPM|Trusted Platform Modules]]: {{ic|tpm}} <br />
CD_MODULES="$CD_MODULES<br />
cpuid<br />
linuxefi<br />
play<br />
tpm<br />
"<br />
<br />
'''3. the "advanced" modules, [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=ubuntu#n159 see line 159 in its script], consisting of modules:''' <br />
* to boot from [[dm-crypt|plain-mode encrypted]] disks: {{ic|cryptodisk}} <br />
* for all the different hashing and encryption algorithms: {{ic|gcry_...}}<br />
* to boot from [[LUKS]]-encrypted disks: {{ic|luks}} <br />
* to boot from [[LVM]] logical volume disks: {{ic|lvm}}<br />
* to boot from [[RAID]] virtual disks: {{ic|mdraid09}}, {{ic|mdraid1x}}, {{ic|raid5rec}}, {{ic|raid6rec}}<br />
GRUB_MODULES="$CD_MODULES<br />
cryptodisk<br />
gcry_arcfour<br />
gcry_blowfish<br />
gcry_camellia<br />
gcry_cast5<br />
gcry_crc<br />
gcry_des<br />
gcry_dsa<br />
gcry_idea<br />
gcry_md4<br />
gcry_md5<br />
gcry_rfc2268<br />
gcry_rijndael<br />
gcry_rmd160<br />
gcry_rsa<br />
gcry_seed<br />
gcry_serpent<br />
gcry_sha1<br />
gcry_sha256<br />
gcry_sha512<br />
gcry_tiger<br />
gcry_twofish<br />
gcry_whirlpool<br />
luks<br />
lvm<br />
mdraid09<br />
mdraid1x<br />
raid5rec<br />
raid6rec<br />
"<br />
Find out all the GRUB modules that are necessary in your particular Arch Linux Setup. <br />
To be safe, you can just include all modules mentioned above. <br />
If you want to make your boot process with GRUB faster or if you want to save space on the ESP partition, you can omit the ones that you don't need. <br />
After you have compiled your specific list of GRUB_MODULES as a variable, continue: <br />
<br />
You also need a [https://github.com/rhboot/shim/blob/main/SBAT.md Secure Boot Advanced Targeting '''(SBAT)'''] file/section included in the EFI binary, to improve the security; if GRUB is launched from the UEFI shim loader. <br />
This SBAT file/section contains metadata about the GRUB binary (version, maintainer, developer, upstream URL) and makes it easier for shim to block certain GRUB versions from being loaded if they have security vulnerabilities, as explained in the [https://github.com/rhboot/shim/blob/main/SBAT.md "UEFI shim bootloader secure boot life-cycle improvements" document from shim]. Multiple different security vulnerabilities in GRUB were discovered: <br />
* The [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#additional "BootHole" vulnerabilities discovered by Eclypsium and published on 2020-07-29]. <br />
* Some [https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021 more GRUB2 vulnerabilities discovered by the Ubuntu Security Team and published on 2021-03-02]. <br />
<br />
The first-stage UEFI bootloader shim will fail to launch grubx64.efi if the SBAT section from grubx64.efi is missing! <br />
<br />
If GRUB is installed, a sample SBAT csv file is provided under {{ic|/usr/share/grub/sbat.csv}}. <br />
<br />
Reinstall GRUB using the provided {{ic|/usr/share/grub/sbat.csv}} file and all the needed {{ic|GRUB_MODULES}} and sign it:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
# cp ''esp''/GRUB/grubx64.efi ''esp''/boot/grubx64.efi<br />
<br />
Reboot, select the key in ''MokManager'', and Secure Boot should be working.<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 />
== Protecting Secure Boot ==<br />
<br />
The only way to prevent anyone with physical access to disable Secure Boot is to protect the firmware settings with a password.<br />
<br />
Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.<br />
<br />
== Tips and tricks ==<br />
<br />
=== sbctl ===<br />
<br />
{{Pkg|sbctl}} is a user-friendly way of setting up secure boot and signing files.<br />
<br />
{{Note|sbctl does not work with all hardware. How well it will work depends on the manufacturer.}}<br />
<br />
==== Creating and enrolling keys ====<br />
<br />
Before starting, go to your BIOS settings and turn off secure boot. This is different for each device.<br />
<br />
Once you log back in, check the secure boot status:<br />
<br />
$ sbctl status<br />
<br />
You should see that sbctl is not installed and secure boot is disabled.<br />
<br />
Then create your custom secure boot keys:<br />
<br />
# sbctl create-keys<br />
<br />
Enroll your keys, with Microsoft's keys, to the UEFI:<br />
<br />
# sbctl enroll-keys -m<br />
<br />
{{Warning|Some firmware is signed and verified with Microsoft's keys when secure boot is enabled. Not validating devices could brick them. To enroll your keys without enrolling Microsoft's, run: {{ic|# sbctl enroll-keys}}. Only do this if you know what you are doing.}}<br />
<br />
Check the secure boot status again:<br />
<br />
$ sbctl status<br />
<br />
sbctl should be installed now, but secure boot will not work until the boot files have been signed with the keys you just created.<br />
<br />
==== Signing ====<br />
<br />
Check what files need to be signed for secure boot to work:<br />
<br />
# sbctl verify<br />
<br />
Now sign all the unsigned files. Usually the [[kernel]] and the [[boot loader]] need to be signed. For example:<br />
<br />
# sbctl sign -s /boot/vmlinuz-linux<br />
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI<br />
<br />
The files that need to be signed will depend on your system's layout, kernel and boot loader.<br />
<br />
Now you are done! Reboot your system and turn secure boot back on in the BIOS settings. If the boot loader and OS load, secure boot should be working. Check with:<br />
<br />
$ sbctl status<br />
<br />
==== Automatic signing with the pacman hook ====<br />
<br />
sbctl comes with a [[pacman hook]] that automatically signs all new files whenever the [[Kernel|Linux kernel]], [[systemd]] or the [[boot loader]] is updated.<br />
<br />
{{Tip|If you use [[Systemd-boot]] and {{ic|systemd-boot-update.service}}, the [[boot loader]] is only updated after a reboot, and the sbctl [[pacman hook]] will therefore not sign the new file. As a workaround, it can be useful to sign the [[boot loader]] directly in {{ic|/usr/lib/}}, as {{ic|bootctl install}} and {{ic|update}} will automatically recognize and copy ''.efi.signed'' files to the [[ESP]] if present, instead of the normal ''.efi'' file. See {{man|1|bootctl}}.<br />
<br />
# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi<br />
<br />
}}<br />
<br />
== See also ==<br />
<br />
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure boot]]<br />
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [https://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://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]<br />
* [http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]<br />
* National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]<br />
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr<br />
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)<br />
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)<br />
* [http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] by Lennart Poettering (2021-09-23)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=743584Unified Extensible Firmware Interface/Secure Boot2022-08-27T14:34:07Z<p>DasMenschy: /* Shim with key and GRUB */ add question to warning box. Which list of GRUB_MODULES is right?</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Security}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Unified_Extensible_Firmware_Interface#Secure_boot|Secure Boot]] is a security feature found in the [[UEFI]] standard, designed to add a layer of protection to the [[Arch boot process|pre-boot process]]: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.<br />
<br />
As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|cover]], while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and [[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|cons]].<br />
<br />
{{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article and [[#See also|other online resources]]. This article focuses on how to set up Secure Boot in Arch Linux.}}<br />
<br />
== Checking Secure Boot status ==<br />
<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 />
<br />
An easy way to check Secure Boot status on systems using [[systemd]] is to use [[systemd-boot]]:<br />
<br />
{{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}}<br />
<br />
{{bc|$ bootctl status<br />
System:<br />
Firmware: UEFI 2.70 (American Megatrends 5.15)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
Boot into FW: supported<br />
...<br />
}}<br />
<br />
Here we see that Secure Boot is enabled and enforced; other values are {{ic|disabled}} for Secure Boot and {{ic|setup}} for Setup Mode[https://github.com/systemd/systemd/issues/8154#issue-296106251].<br />
<br />
{{Accuracy|This command might display more than five digits even though secure boot is enabled.}}<br />
<br />
Another way to check whether the machine was booted with Secure Boot is to use this command:<br />
<br />
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<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 />
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:<br />
<br />
{{hc|# dmesg {{!}} grep -i secure|<br />
[ 0.013442] Secure boot disabled<br />
[ 0.013442] Secure boot could not be determined<br />
}}<br />
<br />
The kernel messages will otherwise read {{ic|Secure boot enabled}}.<br />
<br />
== Booting an installation medium ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disabling Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.<br />
<br />
[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] images provide a way to use secure boot on installation media.<br />
<br />
=== Disabling 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 [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
=== Remastering the installation image ===<br />
<br />
{{Expansion|Add explicit instructions.}}<br />
<br />
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. Another option would be to borrow the {{ic|BOOTx64.EFI}} (shim) and {{ic|grubx64.efi}} from installation media of another GNU+Linux distribution that supports Secure Boot and modify the GRUB configuration to one's needs. In this case, the authentication chain of Secure Boot in said distribution's installation media should end to the {{ic|grubx64.efi}} ( [https://www.linux-magazine.com/index.php/layout/set/print/Issues/2014/164/The-State-of-Secure-Boot/(tagid)/154 for example Ubuntu]) so that GRUB would boot the unsigned kernel and initramfs from archiso. 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 />
== Implementing Secure Boot ==<br />
<br />
There are certain conditions making for an ideal setup of ''Secure boot'':<br />
<br />
# UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]]<br />
# Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/]<br />
# UEFI directly loads a user-signed [[EFISTUB]] combined kernel image (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface<br />
# Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.<br />
# Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement.<br />
<br />
A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party.<br />
<br />
=== Using your own keys ===<br />
<br />
{{Warning|Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware ([[Wikipedia:OpROM|OpROMs]]), that get executed during boot, [[#Microsoft Windows|are signed using Microsoft 3rd Party UEFI CA certificate]].}}<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 denylisted 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 />
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 />
==== Install efitools ====<br />
<br />
Nearly all of the following sections require you to [[install]] the {{Pkg|efitools}} package.<br />
<br />
==== Backing up current variables ====<br />
<br />
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error.<br />
<br />
Run the following commands to backup all four of the principal Secure Boot variables:<br />
<br />
$ efi-readvar -v PK -o old_PK.esl<br />
$ efi-readvar -v KEK -o old_KEK.esl<br />
$ efi-readvar -v db -o old_db.esl<br />
$ efi-readvar -v dbx -o old_dbx.esl<br />
<br />
If you perform these commands on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft.<br />
<br />
==== Creating keys ====<br />
<br />
===== Manual process =====<br />
<br />
To generate keys, perform the following steps.<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 {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware.<br />
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and 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 />
===== Helper scripts =====<br />
<br />
A helper/convenience script is offered by the author of the reference page on this topic[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys] (requires [[python]]). A mildly edited version is also packaged as {{AUR|sbkeys}}.<br />
<br />
In order to use it, simply create a folder in a secure location (e.g. {{ic|/etc/efi-keys/}} if later use of {{AUR|sbupdate-git}} to automate unified kernel image creation and signing is planned) and run it:<br />
<br />
# mkdir /etc/efi-keys<br />
# cd !$<br />
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh<br />
# chmod +x mkkeys.sh<br />
# ./mkkeys.sh<br />
''Enter a Common Name to embed in the keys, e.g. "Secure Boot"''<br />
<br />
This will produce the required files in different formats.<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, [[#Enrolling keys in firmware|enroll it]].<br />
<br />
==== Signing EFI binaries ====<br />
<br />
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched.<br />
<br />
===== Manually with sbsigntools =====<br />
<br />
Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}.<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* 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 />
<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 />
To sign your kernel and boot manager use ''sbsign'', e.g.:<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 />
{{Warning|Signing kernel only will not protect the initramfs from tampering. See [[Unified kernel image]] to know how to produce a combined image that you can then manually sign with ''sbsign''.}}<br />
<br />
===== Signing the kernel with a pacman hook =====<br />
<br />
You can also use mkinitcpio's [[pacman hook]] to sign the kernel on install and updates.<br />
<br />
Copy {{ic|/usr/share/libalpm/hooks/90-mkinitcpio-install.hook}} to {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}} and {{ic|/usr/share/libalpm/scripts/mkinitcpio-install}} to {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}.<br />
<br />
In {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}}, replace:<br />
<br />
Exec = /usr/share/libalpm/scripts/mkinitcpio-install<br />
<br />
with:<br />
<br />
Exec = /usr/local/share/libalpm/scripts/mkinitcpio-install<br />
<br />
In {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}, replace:<br />
<br />
install -Dm644 "${line}" "/boot/vmlinuz-${pkgbase}"<br />
<br />
with:<br />
<br />
sbsign --key ''/path/to/''db.key --cert ''/path/to/''db.crt --output "/boot/vmlinuz-${pkgbase}" "${line}"<br />
<br />
If you are using systemd-boot, there is a [[Systemd-boot#Automatic update|dedicated pacman hook]] doing this task semi-automatically.<br />
<br />
===== Fully automated unified kernel generation and signing with sbupdate =====<br />
<br />
[https://github.com/andreyv/sbupdate sbupdate] is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through [[pacman hooks]].<br />
<br />
Install {{AUR|sbupdate-git}} and configure it following the instructions given on the project's homepage.[https://github.com/andreyv/sbupdate#sbupdate]<br />
<br />
{{Tip|If using [[systemd-boot]], set {{ic|1=OUT_DIR="EFI/Linux"}} to get your signed kernel images directly recognized without needing configuration. See {{man|7|systemd-boot|FILES}} and [[Systemd-boot#Adding loaders]].}}<br />
<br />
Once configured, simply run {{ic|sbupdate}} as root for first-time image generation.<br />
<br />
{{Note|''sbupdate'' output often contains errors such as {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}}. Those are harmless and can be safely ignored.[https://github.com/andreyv/sbupdate/issues/30]}}<br />
<br />
==== Putting 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 />
==== Enrolling keys in firmware ====<br />
<br />
Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
{{Tip|As the '''dbx''' (forbidden signatures db) is empty, it can be safely left out in the following instructions.}}<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 sbkeysync =====<br />
<br />
Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure -<br />
<br />
/etc/secureboot/keys<br />
├── db<br />
├── dbx<br />
├── KEK<br />
└── PK<br />
<br />
For example using:<br />
<br />
# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}<br />
<br />
Then copy each of the ''.auth'' files that were generated earlier into their respective locations (for example, {{ic|PK.auth}} into {{ic|/etc/secureboot/keys/PK}} and so on).<br />
<br />
If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use:<br />
<br />
# sbkeysync --pk --dry-run --verbose<br />
<br />
Finally, use {{ic|sbkeysync}} to enroll your keys.<br />
<br />
# sbkeysync --verbose<br />
# sbkeysync --verbose --pk<br />
<br />
{{Tip|<br />
* If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}.<br />
* If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}.<br />
}}<br />
<br />
On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy.<br />
<br />
===== Using firmware setup utility =====<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files '''EXCEPT OF {{ic|noPK.auth}}''' files to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
{{Warning|'''Do not copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC!''' If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with his or her own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a safe place where only you have access to. A safe place for the noPK.auth file are:<br />
<br />
* an '''external USB stick with an [[EFI system partition]]''' when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage.<br />
* [[Data-at-rest encryption|encrypted storage on your PC]] when using {{ic|sbkeysync}}.<br />
The [[EFI system partition]] of your PC must not be encrypted according to the UEFI specifications and can be mounted and read on another PC (if your PC is stolen and if the hard drive is taken out and connected to another PC). Copying the {{ic|noPK.auth}} file to the ESP of your PC and deleting it afterwards is also not advisable, because deleted files on the FAT32 [[EFI system partition]] [[File recovery#TestDisk and PhotoRec|can be recovered with tools like PhotoRec]].<br />
}}<br />
<br />
Launch firmware setup utility and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
Firmwares have various different interfaces, see [https://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 />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<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 [https://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]]?|section=Booting Windows with custom bootloader signature}}<br />
<br />
It is usually '''not''' possible to boot Windows by signing its bootloader ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) with a [[#Creating keys|custom, personal key]] with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables:<br />
<br />
* if {{ic|bootmgfw.efi}} contains a signature '''both''' from the "Microsoft Windows Production PCA 2011" '''and''' from your own Secure Boot DB key (so '''two signatures'''), then UEFI firmware implementations like ''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' will not launch {{ic|bootmgfw.efi}} and will throw a security violation error ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}'''): UEFI firmware implementation like this can probably only read the '''first''' signature - not the '''second''' one. Only the certificate for the second signature is enrolled in the UEFI Secure Boot variables, so the Secure Boot verification fails.<br />
* if the "Microsoft Windows Production PCA 2011" signature from the {{ic|bootmgfw.efi}} file is stripped/removed, and only a signature from your own Secure Boot DB key is added to the file, then UEFI will launch the file - but Windows will launch a recovery/repair environment: Windows complains that the Windows installation is broken (because the "Microsoft Windows Production PCA 2011" signature on {{ic|bootmgfw.efi}} file is missing).<br />
<br />
So to [[dual boot with Windows]],<br />
<br />
* you either have to add the hash of {{ic|bootmgfw.efi}} to the list of allowed hashes in the {{ic|DB}} variable; and you have to update the {{ic|DB}} variable every time a Windows Update changes {{ic|bootmgfw.efi}}. This is very tedious, error-prone and not supported by Microsoft; and for example Bitlocker will not work properly anymore with this setup (Bitlocker will ask for your recovery password every time to decrypt your Windows partition).<br />
* or you have to add Microsoft's certificates to the UEFI Secure Boot variables [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has two {{ic|DB}} certificates and one {{ic|KEK}} certificate]:<br />
** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 certificate] must be included in the {{ic|DB}} variable in order to allow the Windows Operating System to load.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 certificate] aka the Microsoft 3rd Party UEFI CA certificate should be included in the {{ic|DB}} variable in order to use third-party binaries like UEFI drivers, option ROMs, {{Pkg|shim}}, etc.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 certificate] should be included in the {{ic|KEK}} variable, in order to "enable revocation of bad images by updating the {{ic|DBX}} and potentially for updating {{ic|DB}} to prepare for newer Windows signed images". However, Windows will also boot without the "Microsoft Corporation KEK CA 2011" certificate.<br />
<br />
Create EFI Signature Lists from Microsoft's DER format {{ic|DB}} certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt<br />
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl<br />
<br />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format {{ic|KEK}} certificate using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}):<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK.esl MicCorKEKCA2011_2011-06-24.crt<br />
<br />
Sign a {{ic|DB}} variable update with your {{ic|KEK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|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 />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Sign a {{ic|KEK}} variable update with your {{ic|PK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|KEK}} certificate:<br />
<br />
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth<br />
<br />
Follow [[#Enrolling keys in firmware]] to enroll {{ic|add_MS_db.auth}} and for strict conformity with Microsoft UEFI Secure Boot requirements {{ic|add_MS_Win_KEK.auth}} into the UEFI Secure Boot Database variables.<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 an allowlist called Machine Owner Key list, abbreviated MokList. 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 />
{{Warning|What Microsoft calls "Secured-core PCs" do not ship with Microsoft 3rd Party UEFI CA certificate (Microsoft Corporation UEFI CA 2011) enrolled.[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot]. The only enrolled DB certificate is the Microsoft Windows Production PCA 2011 certificate which is exclusively used to sign the Windows boot loader.<br />
<br />
The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate.<br />
}}<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 [[#Disabling Secure Boot]].}}<br />
<br />
===== Delete enrolled hash =====<br />
<br />
Every entry of hashes enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hashes to free the space and to prevent outdated programs from booting.<br />
<br />
[[Install]] {{Pkg|efitools}} and copy {{ic|KeyTool.efi}}:<br />
<br />
# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi<br />
<br />
Manage to boot to Preloader and you will see the KeyTool entry. You can then edit hashes in the MOK database.<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|<br />
* 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 />
* Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details.<br />
* It might be worth mentioning that if you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with {{ic|mokutil --disable-validation}}. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows with {{ic|chainloader}} in grub.<br />
}}<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 />
{{Note|<br />
* Make sure you do NOT copy fbx64.efi (which is under the same directory) unless you actually have a valid bootx64.csv to use. Otherwise shim will NOT execute grubx64.efi but will appear to fail to work and just reset the machine.<br />
}}<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 />
Finally, create a new NVRAM entry to boot {{ic|BOOTx64.EFI}}:<br />
<br />
# efibootmgr --verbose --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI<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 />
Target = linux-lts<br />
Target = linux-hardened<br />
Target = linux-zen<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 />
====== Shim with key and GRUB ======<br />
<br />
{{Expansion|1=Which GRUB_MODULES are really necessary after {{ic|--modules}}, which are optional/deprecated? The recommendations in the Internet differ: <br />
* [https://bugs.archlinux.org/task/71382#comment202911 comment 202911 in bug report 71382] recommends a different, longer list of modules than <br />
* [https://bbs.archlinux.org/viewtopic.php?pid=2053794#p2053794 comment 2053794 in this forum thread]<br/>}}<br />
Complete the previous section first.<br />
<br />
Find out all the GRUB modules you need to boot and include them in the GRUB_MODULES variable. Which modules are necessary is not yet clear, please help by improving this section: <br />
* According to {{Bug|71382}}, the list of necessary modules includes: <br />
# GRUB_MODULES="all_video boot btrfs cat configfile cryptodisk echo efi_gop efi_uga efifwsetup efinet ext2 f2fs fat font gcry_rijndael gcry_rsa gcry_serpent gcry_sha256 gcry_twofish gcry_whirlpool gfxmenu gfxterm gzio halt hfsplus http iso9660 loadenv loopback linux lvm lsefi lsefimmap luks luks2 mdraid09 mdraid1x minicmd net normal part_apple part_msdos part_gpt password_pbkdf2 pgp png reboot regexp search search_fs_uuid search_fs_file search_label serial sleep syslinuxcfg test tftp video xfs zstd backtrace chain tpm usb usbserial_common usbserial_pl2303 usbserial_ftdi usbserial_usbdebug keylayouts at_keyboard"<br />
* According to the [https://bbs.archlinux.org/viewtopic.php?pid=2053794 Forum thread "Secureboot Grub 2 (Blocked by secureboot policy)"] however, it also works with a smaller, different list: <br />
# GRUB_MODULES="normal test efi_gop efi_uga search echo linux all_video gfxmenu gfxterm_background gfxterm_menu gfxterm loadenv configfile tpm" <br />
<br />
Reinstall GRUB using {{ic|/usr/share/grub/sbat.csv}} with all the needed modules included and enabled and sign it:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
# cp ''esp''/GRUB/grubx64.efi ''esp''/boot/grubx64.efi<br />
<br />
Since GRUB 2.06.r261.g2f4430cc0, you must install GRUB with all modules you need, not only {{ic|TPM}}. If you omit some modules, GRUB will fail to boot with a message {{ic|error: prohibited by secure boot policy}}. <br />
<br />
Reboot, select the key in ''MokManager'', and Secure Boot should be working.<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 />
== Protecting Secure Boot ==<br />
<br />
The only way to prevent anyone with physical access to disable Secure Boot is to protect the firmware settings with a password.<br />
<br />
Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.<br />
<br />
== Tips and tricks ==<br />
<br />
=== sbctl ===<br />
<br />
{{Pkg|sbctl}} is a user-friendly way of setting up secure boot and signing files.<br />
<br />
{{Note|sbctl does not work with all hardware. How well it will work depends on the manufacturer.}}<br />
<br />
==== Creating and enrolling keys ====<br />
<br />
Before starting, go to your BIOS settings and turn off secure boot. This is different for each device.<br />
<br />
Once you log back in, check the secure boot status:<br />
<br />
$ sbctl status<br />
<br />
You should see that sbctl is not installed and secure boot is disabled.<br />
<br />
Then create your custom secure boot keys:<br />
<br />
# sbctl create-keys<br />
<br />
Enroll your keys, with Microsoft's keys, to the UEFI:<br />
<br />
# sbctl enroll-keys -m<br />
<br />
{{Warning|Some firmware is signed and verified with Microsoft's keys when secure boot is enabled. Not validating devices could brick them. To enroll your keys without enrolling Microsoft's, run: {{ic|# sbctl enroll-keys}}. Only do this if you know what you are doing.}}<br />
<br />
Check the secure boot status again:<br />
<br />
$ sbctl status<br />
<br />
sbctl should be installed now, but secure boot will not work until the boot files have been signed with the keys you just created.<br />
<br />
==== Signing ====<br />
<br />
Check what files need to be signed for secure boot to work:<br />
<br />
# sbctl verify<br />
<br />
Now sign all the unsigned files. Usually the [[kernel]] and the [[boot loader]] need to be signed. For example:<br />
<br />
# sbctl sign -s /boot/vmlinuz-linux<br />
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI<br />
<br />
The files that need to be signed will depend on your system's layout, kernel and boot loader.<br />
<br />
Now you are done! Reboot your system and turn secure boot back on in the BIOS settings. If the boot loader and OS load, secure boot should be working. Check with:<br />
<br />
$ sbctl status<br />
<br />
==== Automatic signing with the pacman hook ====<br />
<br />
sbctl comes with a [[pacman hook]] that automatically signs all new files whenever the [[Kernel|Linux kernel]], [[systemd]] or the [[boot loader]] is updated.<br />
<br />
{{Tip|If you use [[Systemd-boot]] and {{ic|systemd-boot-update.service}}, the [[boot loader]] is only updated after a reboot, and the sbctl [[pacman hook]] will therefore not sign the new file. As a workaround, it can be useful to sign the [[boot loader]] directly in {{ic|/usr/lib/}}, as {{ic|bootctl install}} and {{ic|update}} will automatically recognize and copy ''.efi.signed'' files to the [[ESP]] if present, instead of the normal ''.efi'' file. See {{man|1|bootctl}}.<br />
<br />
# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi<br />
<br />
}}<br />
<br />
== See also ==<br />
<br />
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure boot]]<br />
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [https://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://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]<br />
* [http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]<br />
* National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]<br />
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr<br />
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)<br />
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)<br />
* [http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] by Lennart Poettering (2021-09-23)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=743581Unified Extensible Firmware Interface/Secure Boot2022-08-27T13:43:40Z<p>DasMenschy: /* Shim with key and GRUB */ add modules necessary for GRUB: which modules are really necessary, which are optional or even deprecated? It is not clear.</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Security}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Unified_Extensible_Firmware_Interface#Secure_boot|Secure Boot]] is a security feature found in the [[UEFI]] standard, designed to add a layer of protection to the [[Arch boot process|pre-boot process]]: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.<br />
<br />
As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|cover]], while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and [[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|cons]].<br />
<br />
{{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article and [[#See also|other online resources]]. This article focuses on how to set up Secure Boot in Arch Linux.}}<br />
<br />
== Checking Secure Boot status ==<br />
<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 />
<br />
An easy way to check Secure Boot status on systems using [[systemd]] is to use [[systemd-boot]]:<br />
<br />
{{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}}<br />
<br />
{{bc|$ bootctl status<br />
System:<br />
Firmware: UEFI 2.70 (American Megatrends 5.15)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
Boot into FW: supported<br />
...<br />
}}<br />
<br />
Here we see that Secure Boot is enabled and enforced; other values are {{ic|disabled}} for Secure Boot and {{ic|setup}} for Setup Mode[https://github.com/systemd/systemd/issues/8154#issue-296106251].<br />
<br />
{{Accuracy|This command might display more than five digits even though secure boot is enabled.}}<br />
<br />
Another way to check whether the machine was booted with Secure Boot is to use this command:<br />
<br />
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<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 />
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:<br />
<br />
{{hc|# dmesg {{!}} grep -i secure|<br />
[ 0.013442] Secure boot disabled<br />
[ 0.013442] Secure boot could not be determined<br />
}}<br />
<br />
The kernel messages will otherwise read {{ic|Secure boot enabled}}.<br />
<br />
== Booting an installation medium ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disabling Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.<br />
<br />
[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] images provide a way to use secure boot on installation media.<br />
<br />
=== Disabling 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 [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
=== Remastering the installation image ===<br />
<br />
{{Expansion|Add explicit instructions.}}<br />
<br />
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. Another option would be to borrow the {{ic|BOOTx64.EFI}} (shim) and {{ic|grubx64.efi}} from installation media of another GNU+Linux distribution that supports Secure Boot and modify the GRUB configuration to one's needs. In this case, the authentication chain of Secure Boot in said distribution's installation media should end to the {{ic|grubx64.efi}} ( [https://www.linux-magazine.com/index.php/layout/set/print/Issues/2014/164/The-State-of-Secure-Boot/(tagid)/154 for example Ubuntu]) so that GRUB would boot the unsigned kernel and initramfs from archiso. 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 />
== Implementing Secure Boot ==<br />
<br />
There are certain conditions making for an ideal setup of ''Secure boot'':<br />
<br />
# UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]]<br />
# Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/]<br />
# UEFI directly loads a user-signed [[EFISTUB]] combined kernel image (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface<br />
# Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.<br />
# Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement.<br />
<br />
A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party.<br />
<br />
=== Using your own keys ===<br />
<br />
{{Warning|Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware ([[Wikipedia:OpROM|OpROMs]]), that get executed during boot, [[#Microsoft Windows|are signed using Microsoft 3rd Party UEFI CA certificate]].}}<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 denylisted 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 />
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 />
==== Install efitools ====<br />
<br />
Nearly all of the following sections require you to [[install]] the {{Pkg|efitools}} package.<br />
<br />
==== Backing up current variables ====<br />
<br />
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error.<br />
<br />
Run the following commands to backup all four of the principal Secure Boot variables:<br />
<br />
$ efi-readvar -v PK -o old_PK.esl<br />
$ efi-readvar -v KEK -o old_KEK.esl<br />
$ efi-readvar -v db -o old_db.esl<br />
$ efi-readvar -v dbx -o old_dbx.esl<br />
<br />
If you perform these commands on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft.<br />
<br />
==== Creating keys ====<br />
<br />
===== Manual process =====<br />
<br />
To generate keys, perform the following steps.<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 {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware.<br />
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and 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 />
===== Helper scripts =====<br />
<br />
A helper/convenience script is offered by the author of the reference page on this topic[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys] (requires [[python]]). A mildly edited version is also packaged as {{AUR|sbkeys}}.<br />
<br />
In order to use it, simply create a folder in a secure location (e.g. {{ic|/etc/efi-keys/}} if later use of {{AUR|sbupdate-git}} to automate unified kernel image creation and signing is planned) and run it:<br />
<br />
# mkdir /etc/efi-keys<br />
# cd !$<br />
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh<br />
# chmod +x mkkeys.sh<br />
# ./mkkeys.sh<br />
''Enter a Common Name to embed in the keys, e.g. "Secure Boot"''<br />
<br />
This will produce the required files in different formats.<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, [[#Enrolling keys in firmware|enroll it]].<br />
<br />
==== Signing EFI binaries ====<br />
<br />
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched.<br />
<br />
===== Manually with sbsigntools =====<br />
<br />
Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}.<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* 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 />
<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 />
To sign your kernel and boot manager use ''sbsign'', e.g.:<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 />
{{Warning|Signing kernel only will not protect the initramfs from tampering. See [[Unified kernel image]] to know how to produce a combined image that you can then manually sign with ''sbsign''.}}<br />
<br />
===== Signing the kernel with a pacman hook =====<br />
<br />
You can also use mkinitcpio's [[pacman hook]] to sign the kernel on install and updates.<br />
<br />
Copy {{ic|/usr/share/libalpm/hooks/90-mkinitcpio-install.hook}} to {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}} and {{ic|/usr/share/libalpm/scripts/mkinitcpio-install}} to {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}.<br />
<br />
In {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}}, replace:<br />
<br />
Exec = /usr/share/libalpm/scripts/mkinitcpio-install<br />
<br />
with:<br />
<br />
Exec = /usr/local/share/libalpm/scripts/mkinitcpio-install<br />
<br />
In {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}, replace:<br />
<br />
install -Dm644 "${line}" "/boot/vmlinuz-${pkgbase}"<br />
<br />
with:<br />
<br />
sbsign --key ''/path/to/''db.key --cert ''/path/to/''db.crt --output "/boot/vmlinuz-${pkgbase}" "${line}"<br />
<br />
If you are using systemd-boot, there is a [[Systemd-boot#Automatic update|dedicated pacman hook]] doing this task semi-automatically.<br />
<br />
===== Fully automated unified kernel generation and signing with sbupdate =====<br />
<br />
[https://github.com/andreyv/sbupdate sbupdate] is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through [[pacman hooks]].<br />
<br />
Install {{AUR|sbupdate-git}} and configure it following the instructions given on the project's homepage.[https://github.com/andreyv/sbupdate#sbupdate]<br />
<br />
{{Tip|If using [[systemd-boot]], set {{ic|1=OUT_DIR="EFI/Linux"}} to get your signed kernel images directly recognized without needing configuration. See {{man|7|systemd-boot|FILES}} and [[Systemd-boot#Adding loaders]].}}<br />
<br />
Once configured, simply run {{ic|sbupdate}} as root for first-time image generation.<br />
<br />
{{Note|''sbupdate'' output often contains errors such as {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}}. Those are harmless and can be safely ignored.[https://github.com/andreyv/sbupdate/issues/30]}}<br />
<br />
==== Putting 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 />
==== Enrolling keys in firmware ====<br />
<br />
Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
{{Tip|As the '''dbx''' (forbidden signatures db) is empty, it can be safely left out in the following instructions.}}<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 sbkeysync =====<br />
<br />
Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure -<br />
<br />
/etc/secureboot/keys<br />
├── db<br />
├── dbx<br />
├── KEK<br />
└── PK<br />
<br />
For example using:<br />
<br />
# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}<br />
<br />
Then copy each of the ''.auth'' files that were generated earlier into their respective locations (for example, {{ic|PK.auth}} into {{ic|/etc/secureboot/keys/PK}} and so on).<br />
<br />
If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use:<br />
<br />
# sbkeysync --pk --dry-run --verbose<br />
<br />
Finally, use {{ic|sbkeysync}} to enroll your keys.<br />
<br />
# sbkeysync --verbose<br />
# sbkeysync --verbose --pk<br />
<br />
{{Tip|<br />
* If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}.<br />
* If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}.<br />
}}<br />
<br />
On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy.<br />
<br />
===== Using firmware setup utility =====<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files '''EXCEPT OF {{ic|noPK.auth}}''' files to a [[FAT]] formatted file system (you can use [[EFI system partition]]).<br />
<br />
{{Warning|'''Do not copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC!''' If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with his or her own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a safe place where only you have access to. A safe place for the noPK.auth file are:<br />
<br />
* an '''external USB stick with an [[EFI system partition]]''' when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage.<br />
* [[Data-at-rest encryption|encrypted storage on your PC]] when using {{ic|sbkeysync}}.<br />
The [[EFI system partition]] of your PC must not be encrypted according to the UEFI specifications and can be mounted and read on another PC (if your PC is stolen and if the hard drive is taken out and connected to another PC). Copying the {{ic|noPK.auth}} file to the ESP of your PC and deleting it afterwards is also not advisable, because deleted files on the FAT32 [[EFI system partition]] [[File recovery#TestDisk and PhotoRec|can be recovered with tools like PhotoRec]].<br />
}}<br />
<br />
Launch firmware setup utility and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
Firmwares have various different interfaces, see [https://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 />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<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 [https://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]]?|section=Booting Windows with custom bootloader signature}}<br />
<br />
It is usually '''not''' possible to boot Windows by signing its bootloader ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) with a [[#Creating keys|custom, personal key]] with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables:<br />
<br />
* if {{ic|bootmgfw.efi}} contains a signature '''both''' from the "Microsoft Windows Production PCA 2011" '''and''' from your own Secure Boot DB key (so '''two signatures'''), then UEFI firmware implementations like ''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' will not launch {{ic|bootmgfw.efi}} and will throw a security violation error ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}'''): UEFI firmware implementation like this can probably only read the '''first''' signature - not the '''second''' one. Only the certificate for the second signature is enrolled in the UEFI Secure Boot variables, so the Secure Boot verification fails.<br />
* if the "Microsoft Windows Production PCA 2011" signature from the {{ic|bootmgfw.efi}} file is stripped/removed, and only a signature from your own Secure Boot DB key is added to the file, then UEFI will launch the file - but Windows will launch a recovery/repair environment: Windows complains that the Windows installation is broken (because the "Microsoft Windows Production PCA 2011" signature on {{ic|bootmgfw.efi}} file is missing).<br />
<br />
So to [[dual boot with Windows]],<br />
<br />
* you either have to add the hash of {{ic|bootmgfw.efi}} to the list of allowed hashes in the {{ic|DB}} variable; and you have to update the {{ic|DB}} variable every time a Windows Update changes {{ic|bootmgfw.efi}}. This is very tedious, error-prone and not supported by Microsoft; and for example Bitlocker will not work properly anymore with this setup (Bitlocker will ask for your recovery password every time to decrypt your Windows partition).<br />
* or you have to add Microsoft's certificates to the UEFI Secure Boot variables [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has two {{ic|DB}} certificates and one {{ic|KEK}} certificate]:<br />
** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 certificate] must be included in the {{ic|DB}} variable in order to allow the Windows Operating System to load.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 certificate] aka the Microsoft 3rd Party UEFI CA certificate should be included in the {{ic|DB}} variable in order to use third-party binaries like UEFI drivers, option ROMs, {{Pkg|shim}}, etc.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 certificate] should be included in the {{ic|KEK}} variable, in order to "enable revocation of bad images by updating the {{ic|DBX}} and potentially for updating {{ic|DB}} to prepare for newer Windows signed images". However, Windows will also boot without the "Microsoft Corporation KEK CA 2011" certificate.<br />
<br />
Create EFI Signature Lists from Microsoft's DER format {{ic|DB}} certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt<br />
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl<br />
<br />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format {{ic|KEK}} certificate using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}):<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK.esl MicCorKEKCA2011_2011-06-24.crt<br />
<br />
Sign a {{ic|DB}} variable update with your {{ic|KEK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|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 />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Sign a {{ic|KEK}} variable update with your {{ic|PK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|KEK}} certificate:<br />
<br />
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth<br />
<br />
Follow [[#Enrolling keys in firmware]] to enroll {{ic|add_MS_db.auth}} and for strict conformity with Microsoft UEFI Secure Boot requirements {{ic|add_MS_Win_KEK.auth}} into the UEFI Secure Boot Database variables.<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 an allowlist called Machine Owner Key list, abbreviated MokList. 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 />
{{Warning|What Microsoft calls "Secured-core PCs" do not ship with Microsoft 3rd Party UEFI CA certificate (Microsoft Corporation UEFI CA 2011) enrolled.[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot]. The only enrolled DB certificate is the Microsoft Windows Production PCA 2011 certificate which is exclusively used to sign the Windows boot loader.<br />
<br />
The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate.<br />
}}<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 [[#Disabling Secure Boot]].}}<br />
<br />
===== Delete enrolled hash =====<br />
<br />
Every entry of hashes enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hashes to free the space and to prevent outdated programs from booting.<br />
<br />
[[Install]] {{Pkg|efitools}} and copy {{ic|KeyTool.efi}}:<br />
<br />
# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi<br />
<br />
Manage to boot to Preloader and you will see the KeyTool entry. You can then edit hashes in the MOK database.<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|<br />
* 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 />
* Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details.<br />
* It might be worth mentioning that if you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with {{ic|mokutil --disable-validation}}. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows with {{ic|chainloader}} in grub.<br />
}}<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 />
{{Note|<br />
* Make sure you do NOT copy fbx64.efi (which is under the same directory) unless you actually have a valid bootx64.csv to use. Otherwise shim will NOT execute grubx64.efi but will appear to fail to work and just reset the machine.<br />
}}<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 />
Finally, create a new NVRAM entry to boot {{ic|BOOTx64.EFI}}:<br />
<br />
# efibootmgr --verbose --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI<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 />
Target = linux-lts<br />
Target = linux-hardened<br />
Target = linux-zen<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 />
====== Shim with key and GRUB ======<br />
<br />
{{Expansion|Related to {{Bug|71382}}? Provide a {{ic|--modules}} option that works for everyone.}}<br />
<br />
Complete the previous section first.<br />
<br />
Find out all the GRUB modules you need to boot and include them in the GRUB_MODULES variable. Which modules are necessary is not yet clear, please help by improving this section: <br />
* According to the [https://bugs.archlinux.org/task/71382 Bug Report FS#71382], the list of necessary modules includes: <br />
# GRUB_MODULES="all_video boot btrfs cat configfile cryptodisk echo efi_gop efi_uga efifwsetup efinet ext2 f2fs fat font gcry_rijndael gcry_rsa gcry_serpent gcry_sha256 gcry_twofish gcry_whirlpool gfxmenu gfxterm gzio halt hfsplus http iso9660 loadenv loopback linux lvm lsefi lsefimmap luks luks2 mdraid09 mdraid1x minicmd net normal part_apple part_msdos part_gpt password_pbkdf2 pgp png reboot regexp search search_fs_uuid search_fs_file search_label serial sleep syslinuxcfg test tftp video xfs zstd backtrace chain tpm usb usbserial_common usbserial_pl2303 usbserial_ftdi usbserial_usbdebug keylayouts at_keyboard"<br />
* According to the [https://bbs.archlinux.org/viewtopic.php?pid=2053794 Forum thread "Secureboot Grub 2 (Blocked by secureboot policy)"] however, it also works with a smaller, different list: <br />
# GRUB_MODULES="normal test efi_gop efi_uga search echo linux all_video gfxmenu gfxterm_background gfxterm_menu gfxterm loadenv configfile tpm" <br />
<br />
Reinstall GRUB using {{ic|/usr/share/grub/sbat.csv}} with all the needed modules included and enabled and sign it:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
# cp ''esp''/GRUB/grubx64.efi ''esp''/boot/grubx64.efi<br />
<br />
Since GRUB 2.06.r261.g2f4430cc0, you must install GRUB with all modules you need, not only {{ic|TPM}}. If you omit some modules, GRUB will fail to boot with a message {{ic|error: prohibited by secure boot policy}}. <br />
<br />
Reboot, select the key in ''MokManager'', and Secure Boot should be working.<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 />
== Protecting Secure Boot ==<br />
<br />
The only way to prevent anyone with physical access to disable Secure Boot is to protect the firmware settings with a password.<br />
<br />
Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.<br />
<br />
== Tips and tricks ==<br />
<br />
=== sbctl ===<br />
<br />
{{Pkg|sbctl}} is a user-friendly way of setting up secure boot and signing files.<br />
<br />
{{Note|sbctl does not work with all hardware. How well it will work depends on the manufacturer.}}<br />
<br />
==== Creating and enrolling keys ====<br />
<br />
Before starting, go to your BIOS settings and turn off secure boot. This is different for each device.<br />
<br />
Once you log back in, check the secure boot status:<br />
<br />
$ sbctl status<br />
<br />
You should see that sbctl is not installed and secure boot is disabled.<br />
<br />
Then create your custom secure boot keys:<br />
<br />
# sbctl create-keys<br />
<br />
Enroll your keys, with Microsoft's keys, to the UEFI:<br />
<br />
# sbctl enroll-keys -m<br />
<br />
{{Warning|Some firmware is signed and verified with Microsoft's keys when secure boot is enabled. Not validating devices could brick them. To enroll your keys without enrolling Microsoft's, run: {{ic|# sbctl enroll-keys}}. Only do this if you know what you are doing.}}<br />
<br />
Check the secure boot status again:<br />
<br />
$ sbctl status<br />
<br />
sbctl should be installed now, but secure boot will not work until the boot files have been signed with the keys you just created.<br />
<br />
==== Signing ====<br />
<br />
Check what files need to be signed for secure boot to work:<br />
<br />
# sbctl verify<br />
<br />
Now sign all the unsigned files. Usually the [[kernel]] and the [[boot loader]] need to be signed. For example:<br />
<br />
# sbctl sign -s /boot/vmlinuz-linux<br />
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI<br />
<br />
The files that need to be signed will depend on your system's layout, kernel and boot loader.<br />
<br />
Now you are done! Reboot your system and turn secure boot back on in the BIOS settings. If the boot loader and OS load, secure boot should be working. Check with:<br />
<br />
$ sbctl status<br />
<br />
==== Automatic signing with the pacman hook ====<br />
<br />
sbctl comes with a [[pacman hook]] that automatically signs all new files whenever the [[Kernel|Linux kernel]], [[systemd]] or the [[boot loader]] is updated.<br />
<br />
{{Tip|If you use [[Systemd-boot]] and {{ic|systemd-boot-update.service}}, the [[boot loader]] is only updated after a reboot, and the sbctl [[pacman hook]] will therefore not sign the new file. As a workaround, it can be useful to sign the [[boot loader]] directly in {{ic|/usr/lib/}}, as {{ic|bootctl install}} and {{ic|update}} will automatically recognize and copy ''.efi.signed'' files to the [[ESP]] if present, instead of the normal ''.efi'' file. See {{man|1|bootctl}}.<br />
<br />
# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi<br />
<br />
}}<br />
<br />
== See also ==<br />
<br />
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure boot]]<br />
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [https://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://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]<br />
* [http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]<br />
* National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]<br />
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr<br />
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)<br />
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)<br />
* [http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] by Lennart Poettering (2021-09-23)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Access_levels_and_roles&diff=742939ArchWiki talk:Access levels and roles2022-08-23T09:49:37Z<p>DasMenschy: /* Allow autoconfirmed or privileged users to upload pictures, not only sysops */ Why I don't like Rodsbooks that much</p>
<hr />
<div>== Some inconsistencies ==<br />
<br />
With the last [[Special:Log/rights|update of group rights]] I went over the relevant articles again and noticed the following:<br />
* The "disambiguation" page [[Roles]] does not mention this article at all. Arguably there is an overlap between both articles, and the little content [[Roles]] has could be merged back here or to [[Arch terminology]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:About [[Roles]] not linking here, it can be an easy fix, for example we can disambiguate between ''Arch Linux'' (or the global community) roles, and the more specific ''ArchWiki'' roles, which have a more technical reason to be.<br />
:Merging [[Roles]] into an ArchWiki-namespace page like this one would reduce its scope to the wiki-specific pages, thus possibly generating another inconsistency.<br />
:I think [[Roles]] can make sense in the context of [[:Category:Teams]] to give a place where to mention all the official staff sections that don't have their own wiki Team page.<br />
:Merging [[Roles#Package maintainer]] into [[Arch terminology]] finds me in agreement instead: "package maintainer" isn't a community role, in fact in its definition it already says that it's some kind of a more generic ''term'' to describe Devs, TUs and generic AUR maintainers (the latter not even forming a team).<br />
:Perhaps we may rename the article to something like "Arch Linux Teams"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Statistics]] mentions the "maximum" of Administrator and Maintainer, whereas both [[ArchWiki:Maintainers]] and [[ArchWiki:Administrators]] redirect to [[ArchWiki:Maintenance Team#Active maintainers]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:The legend says that the "Roles" column hosts "a ''human-readable'' representation of the most relevant access levels and roles", so not 1:1, for clarity (wiki user groups aren't intended to be directly human readable) and tradition ("administrator" is a globally recognized term to identify users with the main coordination responsibility).<br />
:Of course you only reported the inconsistency here, but it could be interesting to discuss improvements, for example changing [[ArchWiki:Administrators|Administrator]] to [[ArchWiki:Maintainers|Maintainer<sup>admin</sup>]] (I'm not endorsing that, it's only an example).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Maintenance Team]] lists {{ic|administrator}} as an "extra group", when the actual group is {{ic|sysop}}. Moreover, other groups like {{ic|archtu}} or {{ic|archstaff}} are not included in the columns. (With latter admittedly only being relevant to me...)<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:I suppose the intention of "Extra groups" is more exactly to list the access level of wiki maintainers (that being the Maintenance Team page), i.e. "cosysop" is implicit (blank), "sysop" is called "administrator" by convention, and the highest access level for a maintainer is "bureaucrat". I think mentioning other wiki roles could be a bit out of scope in that table.<br />
:Maybe the column could be renamed "Access level"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* The {{ic|archstaff}} group is given to users with "other roles in the Arch community", when this term is more generally used for ''any'' staff members, wiki admins included. [https://www.archlinux.org/people/support-staff/] That non-admin maintainers are not included in aforementioned list, but do have a special title on the Forums, only adds to the mystery.<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:Again, I wouldn't take the wiki group names with their literal meaning, perhaps we could have named {{ic|archstaff}} {{ic|archotherstaffroles}} instead, but I thought it would be neater to keep it short :)<br />
:Should we explicitly warn that wiki group names shouldn't be interpreted literally and are more meant to be configuration-file-friendly than realistic descriptions of the community roles?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
== <s>Allow autoconfirmed or privileged users to upload pictures, not only sysops</s> ==<br />
<br />
I would like to upload screenshots/pictures that show - step by step - how to enable/disable Secure Boot, how to enable Setup Mode in the UEFI BIOS Settings of a [[Lenovo ThinkPad X1 Carbon (Gen 5)]]. <br />
<br />
Unfortunately, according to [[Special:Upload]], uploading pictures is "limited to users in the group: sysop". It would be nice if that requirement could be lowered, so that for example '''autoconfirmed''' or '''privileged''' users could do it as well. <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:58, 22 August 2022 (UTC)<br />
<br />
: This is covered in [[Help:Style#Non-pertinent content]]. Closing. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:12, 23 August 2022 (UTC)<br />
<br />
::Hm, pity. I have to point out however that the linked sentence "Necessity: Arch does not develop nor maintain any sort of GUI application, so we do not need to display any screenshot." is wrong/misleading: Disabling UEFI Secure Boot is necessary to boot the Arch installation medium. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:06, 23 August 2022 (UTC)<br />
<br />
:::For this specific case, a link to any external medium would still be possible, but a description inside the page would be preferred, e.g. for a blind user wanting to follow the steps. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:18, 23 August 2022 (UTC)<br />
<br />
::::For step by step instructions with screenshots (where every step needs another picture), it is impractical to link to another site, IMHO: the Arch Wiki visitor then has to click again and again on links to load them. The pictures are not preloaded. Anyway, this is the Arch Wiki Maintainers decision, that I have to respect, so I should maybe put the instructions on another website. Thank you for your help! Case closed. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:38, 23 August 2022 (UTC)<br />
<br />
:::::I had pictured the following: a step by step description, with a link at the end to an album with all the screenshots in the same order (à la imgur galleries). Glad I could be useful. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:11, 23 August 2022 (UTC)<br />
<br />
:::::For disabling Secure Boot, [[Unified Extensible Firmware Interface/Secure Boot#Disabling Secure Boot]] already links to [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable instructions with pictures on Rod Smith's site]. You can email him if there's something more to add to that page. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 23 August 2022 (UTC)<br />
<br />
::::::I think that Rodsbooks page is a bit confusing and chaotic, and it also doesn't have screenshots for every step; only one screenshot for every device. And the screenshots there are also not that high-quality (made with smartphone cameras). I made high-quality UEFI Setup screenshots for every step for my device (i could actually make a film / GIF out of them, which I did); with a screengrabber HDMI-to-USB3 tool; that's why I thought putting them on the Arch Wiki is better, where I can change the layout and make it more clear. Anyway, maybe Rod Smith could make his site better with my screenshots. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 09:49, 23 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Access_levels_and_roles&diff=742869ArchWiki talk:Access levels and roles2022-08-23T07:38:55Z<p>DasMenschy: /* Allow autoconfirmed or privileged users to upload pictures, not only sysops */ Case Close</p>
<hr />
<div>== Some inconsistencies ==<br />
<br />
With the last [[Special:Log/rights|update of group rights]] I went over the relevant articles again and noticed the following:<br />
* The "disambiguation" page [[Roles]] does not mention this article at all. Arguably there is an overlap between both articles, and the little content [[Roles]] has could be merged back here or to [[Arch terminology]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:About [[Roles]] not linking here, it can be an easy fix, for example we can disambiguate between ''Arch Linux'' (or the global community) roles, and the more specific ''ArchWiki'' roles, which have a more technical reason to be.<br />
:Merging [[Roles]] into an ArchWiki-namespace page like this one would reduce its scope to the wiki-specific pages, thus possibly generating another inconsistency.<br />
:I think [[Roles]] can make sense in the context of [[:Category:Teams]] to give a place where to mention all the official staff sections that don't have their own wiki Team page.<br />
:Merging [[Roles#Package maintainer]] into [[Arch terminology]] finds me in agreement instead: "package maintainer" isn't a community role, in fact in its definition it already says that it's some kind of a more generic ''term'' to describe Devs, TUs and generic AUR maintainers (the latter not even forming a team).<br />
:Perhaps we may rename the article to something like "Arch Linux Teams"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Statistics]] mentions the "maximum" of Administrator and Maintainer, whereas both [[ArchWiki:Maintainers]] and [[ArchWiki:Administrators]] redirect to [[ArchWiki:Maintenance Team#Active maintainers]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:The legend says that the "Roles" column hosts "a ''human-readable'' representation of the most relevant access levels and roles", so not 1:1, for clarity (wiki user groups aren't intended to be directly human readable) and tradition ("administrator" is a globally recognized term to identify users with the main coordination responsibility).<br />
:Of course you only reported the inconsistency here, but it could be interesting to discuss improvements, for example changing [[ArchWiki:Administrators|Administrator]] to [[ArchWiki:Maintainers|Maintainer<sup>admin</sup>]] (I'm not endorsing that, it's only an example).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Maintenance Team]] lists {{ic|administrator}} as an "extra group", when the actual group is {{ic|sysop}}. Moreover, other groups like {{ic|archtu}} or {{ic|archstaff}} are not included in the columns. (With latter admittedly only being relevant to me...)<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:I suppose the intention of "Extra groups" is more exactly to list the access level of wiki maintainers (that being the Maintenance Team page), i.e. "cosysop" is implicit (blank), "sysop" is called "administrator" by convention, and the highest access level for a maintainer is "bureaucrat". I think mentioning other wiki roles could be a bit out of scope in that table.<br />
:Maybe the column could be renamed "Access level"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* The {{ic|archstaff}} group is given to users with "other roles in the Arch community", when this term is more generally used for ''any'' staff members, wiki admins included. [https://www.archlinux.org/people/support-staff/] That non-admin maintainers are not included in aforementioned list, but do have a special title on the Forums, only adds to the mystery.<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:Again, I wouldn't take the wiki group names with their literal meaning, perhaps we could have named {{ic|archstaff}} {{ic|archotherstaffroles}} instead, but I thought it would be neater to keep it short :)<br />
:Should we explicitly warn that wiki group names shouldn't be interpreted literally and are more meant to be configuration-file-friendly than realistic descriptions of the community roles?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
== <s>Allow autoconfirmed or privileged users to upload pictures, not only sysops</s> ==<br />
<br />
I would like to upload screenshots/pictures that show - step by step - how to enable/disable Secure Boot, how to enable Setup Mode in the UEFI BIOS Settings of a [[Lenovo ThinkPad X1 Carbon (Gen 5)]]. <br />
<br />
Unfortunately, according to [[Special:Upload]], uploading pictures is "limited to users in the group: sysop". It would be nice if that requirement could be lowered, so that for example '''autoconfirmed''' or '''privileged''' users could do it as well. <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:58, 22 August 2022 (UTC)<br />
<br />
: This is covered in [[Help:Style#Non-pertinent content]]. Closing. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:12, 23 August 2022 (UTC)<br />
<br />
::Hm, pity. I have to point out however that the linked sentence "Necessity: Arch does not develop nor maintain any sort of GUI application, so we do not need to display any screenshot." is wrong/misleading: Disabling UEFI Secure Boot is necessary to boot the Arch installation medium. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:06, 23 August 2022 (UTC)<br />
<br />
:::For this specific case, a link to any external medium would still be possible, but a description inside the page would be preferred, e.g. for a blind user wanting to follow the steps. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 07:18, 23 August 2022 (UTC)<br />
<br />
::::For step by step instructions with screenshots (where every step needs another picture), it is impractical to link to another site, IMHO: the Arch Wiki visitor then has to click again and again on links to load them. The pictures are not preloaded. Anyway, this is the Arch Wiki Maintainers decision, that I have to respect, so I should maybe put the instructions on another website. Thank you for your help! Case closed. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:38, 23 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Access_levels_and_roles&diff=742860ArchWiki talk:Access levels and roles2022-08-23T07:06:39Z<p>DasMenschy: /* Allow autoconfirmed or privileged users to upload pictures, not only sysops */ : disabling secure boot is necessary to boot the Arch installation medium</p>
<hr />
<div>== Some inconsistencies ==<br />
<br />
With the last [[Special:Log/rights|update of group rights]] I went over the relevant articles again and noticed the following:<br />
* The "disambiguation" page [[Roles]] does not mention this article at all. Arguably there is an overlap between both articles, and the little content [[Roles]] has could be merged back here or to [[Arch terminology]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:About [[Roles]] not linking here, it can be an easy fix, for example we can disambiguate between ''Arch Linux'' (or the global community) roles, and the more specific ''ArchWiki'' roles, which have a more technical reason to be.<br />
:Merging [[Roles]] into an ArchWiki-namespace page like this one would reduce its scope to the wiki-specific pages, thus possibly generating another inconsistency.<br />
:I think [[Roles]] can make sense in the context of [[:Category:Teams]] to give a place where to mention all the official staff sections that don't have their own wiki Team page.<br />
:Merging [[Roles#Package maintainer]] into [[Arch terminology]] finds me in agreement instead: "package maintainer" isn't a community role, in fact in its definition it already says that it's some kind of a more generic ''term'' to describe Devs, TUs and generic AUR maintainers (the latter not even forming a team).<br />
:Perhaps we may rename the article to something like "Arch Linux Teams"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Statistics]] mentions the "maximum" of Administrator and Maintainer, whereas both [[ArchWiki:Maintainers]] and [[ArchWiki:Administrators]] redirect to [[ArchWiki:Maintenance Team#Active maintainers]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:The legend says that the "Roles" column hosts "a ''human-readable'' representation of the most relevant access levels and roles", so not 1:1, for clarity (wiki user groups aren't intended to be directly human readable) and tradition ("administrator" is a globally recognized term to identify users with the main coordination responsibility).<br />
:Of course you only reported the inconsistency here, but it could be interesting to discuss improvements, for example changing [[ArchWiki:Administrators|Administrator]] to [[ArchWiki:Maintainers|Maintainer<sup>admin</sup>]] (I'm not endorsing that, it's only an example).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Maintenance Team]] lists {{ic|administrator}} as an "extra group", when the actual group is {{ic|sysop}}. Moreover, other groups like {{ic|archtu}} or {{ic|archstaff}} are not included in the columns. (With latter admittedly only being relevant to me...)<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:I suppose the intention of "Extra groups" is more exactly to list the access level of wiki maintainers (that being the Maintenance Team page), i.e. "cosysop" is implicit (blank), "sysop" is called "administrator" by convention, and the highest access level for a maintainer is "bureaucrat". I think mentioning other wiki roles could be a bit out of scope in that table.<br />
:Maybe the column could be renamed "Access level"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* The {{ic|archstaff}} group is given to users with "other roles in the Arch community", when this term is more generally used for ''any'' staff members, wiki admins included. [https://www.archlinux.org/people/support-staff/] That non-admin maintainers are not included in aforementioned list, but do have a special title on the Forums, only adds to the mystery.<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:Again, I wouldn't take the wiki group names with their literal meaning, perhaps we could have named {{ic|archstaff}} {{ic|archotherstaffroles}} instead, but I thought it would be neater to keep it short :)<br />
:Should we explicitly warn that wiki group names shouldn't be interpreted literally and are more meant to be configuration-file-friendly than realistic descriptions of the community roles?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
== <s>Allow autoconfirmed or privileged users to upload pictures, not only sysops</s> ==<br />
<br />
I would like to upload screenshots/pictures that show - step by step - how to enable/disable Secure Boot, how to enable Setup Mode in the UEFI BIOS Settings of a [[Lenovo ThinkPad X1 Carbon (Gen 5)]]. <br />
<br />
Unfortunately, according to [[Special:Upload]], uploading pictures is "limited to users in the group: sysop". It would be nice if that requirement could be lowered, so that for example '''autoconfirmed''' or '''privileged''' users could do it as well. <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:58, 22 August 2022 (UTC)<br />
<br />
: This is covered in [[Help:Style#Non-pertinent content]]. Closing. --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:12, 23 August 2022 (UTC)<br />
<br />
::Hm, pity. I have to point out however that the linked sentence "Necessity: Arch does not develop nor maintain any sort of GUI application, so we do not need to display any screenshot." is wrong/misleading: Disabling UEFI Secure Boot is necessary to boot the Arch installation medium. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:06, 23 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Access_levels_and_roles&diff=742770ArchWiki talk:Access levels and roles2022-08-22T07:58:11Z<p>DasMenschy: /* Allow autoconfirmed or privileged users to upload pictures, not only sysops */ new section</p>
<hr />
<div>== Some inconsistencies ==<br />
<br />
With the last [[Special:Log/rights|update of group rights]] I went over the relevant articles again and noticed the following:<br />
* The "disambiguation" page [[Roles]] does not mention this article at all. Arguably there is an overlap between both articles, and the little content [[Roles]] has could be merged back here or to [[Arch terminology]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:About [[Roles]] not linking here, it can be an easy fix, for example we can disambiguate between ''Arch Linux'' (or the global community) roles, and the more specific ''ArchWiki'' roles, which have a more technical reason to be.<br />
:Merging [[Roles]] into an ArchWiki-namespace page like this one would reduce its scope to the wiki-specific pages, thus possibly generating another inconsistency.<br />
:I think [[Roles]] can make sense in the context of [[:Category:Teams]] to give a place where to mention all the official staff sections that don't have their own wiki Team page.<br />
:Merging [[Roles#Package maintainer]] into [[Arch terminology]] finds me in agreement instead: "package maintainer" isn't a community role, in fact in its definition it already says that it's some kind of a more generic ''term'' to describe Devs, TUs and generic AUR maintainers (the latter not even forming a team).<br />
:Perhaps we may rename the article to something like "Arch Linux Teams"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Statistics]] mentions the "maximum" of Administrator and Maintainer, whereas both [[ArchWiki:Maintainers]] and [[ArchWiki:Administrators]] redirect to [[ArchWiki:Maintenance Team#Active maintainers]].<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:The legend says that the "Roles" column hosts "a ''human-readable'' representation of the most relevant access levels and roles", so not 1:1, for clarity (wiki user groups aren't intended to be directly human readable) and tradition ("administrator" is a globally recognized term to identify users with the main coordination responsibility).<br />
:Of course you only reported the inconsistency here, but it could be interesting to discuss improvements, for example changing [[ArchWiki:Administrators|Administrator]] to [[ArchWiki:Maintainers|Maintainer<sup>admin</sup>]] (I'm not endorsing that, it's only an example).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* [[ArchWiki:Maintenance Team]] lists {{ic|administrator}} as an "extra group", when the actual group is {{ic|sysop}}. Moreover, other groups like {{ic|archtu}} or {{ic|archstaff}} are not included in the columns. (With latter admittedly only being relevant to me...)<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:I suppose the intention of "Extra groups" is more exactly to list the access level of wiki maintainers (that being the Maintenance Team page), i.e. "cosysop" is implicit (blank), "sysop" is called "administrator" by convention, and the highest access level for a maintainer is "bureaucrat". I think mentioning other wiki roles could be a bit out of scope in that table.<br />
:Maybe the column could be renamed "Access level"?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
* The {{ic|archstaff}} group is given to users with "other roles in the Arch community", when this term is more generally used for ''any'' staff members, wiki admins included. [https://www.archlinux.org/people/support-staff/] That non-admin maintainers are not included in aforementioned list, but do have a special title on the Forums, only adds to the mystery.<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:19, 8 July 2019 (UTC)<br />
<br />
:Again, I wouldn't take the wiki group names with their literal meaning, perhaps we could have named {{ic|archstaff}} {{ic|archotherstaffroles}} instead, but I thought it would be neater to keep it short :)<br />
:Should we explicitly warn that wiki group names shouldn't be interpreted literally and are more meant to be configuration-file-friendly than realistic descriptions of the community roles?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:08, 9 July 2019 (UTC)<br />
<br />
== Allow autoconfirmed or privileged users to upload pictures, not only sysops ==<br />
<br />
I would like to upload screenshots/pictures that show - step by step - how to enable/disable Secure Boot, how to enable Setup Mode in the UEFI BIOS Settings of a [[Lenovo ThinkPad X1 Carbon (Gen 5)]]. <br />
<br />
Unfortunately, according to [[Special:Upload]], uploading pictures is "limited to users in the group: sysop". It would be nice if that requirement could be lowered, so that for example '''autoconfirmed''' or '''privileged''' users could do it as well. <br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 07:58, 22 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=740279Talk:Unified Extensible Firmware Interface/Secure Boot2022-08-05T21:27:36Z<p>DasMenschy: /* about restoring OEM keys */ Yes, it should be mentioned in the article that restoring OEM keys is possible in many UEFI implementations</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
:I personally had many more digits, but that's because the <code>SecureBoot*</code> glob matches a <code>SecureBootSetup-...</code> file. If I use <code>SecureBoot-*</code> (note the dash), I get the expected output (secure boot is disabled on my system):<br />
<nowiki>od -An -tu1 /sys/firmware/efi/efivars/SecureBoot-*<br />
6 0 0 0 0</nowiki><br />
:--[[User:PsYchotic|PsYchotic]] ([[User talk:PsYchotic|talk]]) 18:53, 1 June 2022 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
:::Figured. Most people I see that provision their own Secure Boot keys do so due to their distrust in Microsoft.<br />
:::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).<br />
:::About the {{ic|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.<br />
:::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?<br />
:::[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 02:17, 22 December 2021 (UTC)<br />
<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
: The current warning isn't much help in finding out if one's device is going to be affected. Is [https://github.com/Foxboron/sbctl/wiki/FAQ this] reliable enough to be added to the wiki as a possible check ? --[[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 21:44, 30 December 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)<br />
:: There isn't any easy tools for doing any of this which is why I started writing [https://github.com/Foxboron/sbctl sbctl]]. However I'm not super comfortable adding it to Arch Wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 19:44, 2 January 2022 (UTC)<br />
:::: 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.<br />
:::: [[User:Kiasoc5|Kiasoc5]] ([[User talk:Kiasoc5|talk]]) 19:16, 16 May 2022 (UTC)<br />
<br />
== about restoring OEM keys ==<br />
This is a little off-topic, but:<br />
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<br />
<br />
{{unsigned|14:12, 5 August 2022|Solstice}}<br />
: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? <br />
:* Option 1: At the end of section [[Secure Boot#Using your own keys|"3.1 Using your own keys"]], just after [[Secure Boot#Dual booting with other operating systems|"3.1.7 Dual booting with other operating systems"]], a section: '''"3.1.8 Restoring the OEM Secure Boot variables"'''?<br />
:* Option 2: Or included in the section [[Secure Boot#Backing up current variables|"3.1.2 Backing up current variables"]]? <br />
:[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:27, 5 August 2022 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=739966Unified Extensible Firmware Interface/Secure Boot2022-08-03T16:45:42Z<p>DasMenschy: /* Microsoft Windows */ Giving some more information about dual-booting Linux and Windows</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Security}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Unified_Extensible_Firmware_Interface#Secure_boot|Secure Boot]] is a security feature found in the [[UEFI]] standard, designed to add a layer of protection to the [[Arch boot process|pre-boot process]]: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.<br />
<br />
As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|cover]], while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and [[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|cons]].<br />
<br />
{{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article and [[#See also|other online resources]]. This article focuses on how to set up Secure Boot in Arch Linux.}}<br />
<br />
== Checking Secure Boot status ==<br />
<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 />
<br />
An easy way to check Secure Boot status on systems using [[systemd]] is to use [[systemd-boot]]:<br />
<br />
{{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}}<br />
<br />
{{bc|$ bootctl status<br />
System:<br />
Firmware: UEFI 2.70 (American Megatrends 5.15)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
Boot into FW: supported<br />
...}}<br />
<br />
Here we see that Secure Boot is enabled and enforced; other values are {{ic|disabled}} for Secure Boot and {{ic|setup}} for Setup Mode[https://github.com/systemd/systemd/issues/8154#issue-296106251].<br />
<br />
{{Accuracy|This command might display more than five digits even though secure boot is enabled.}}<br />
<br />
Another way to check whether the machine was booted with Secure Boot is to use this command:<br />
<br />
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<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 />
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:<br />
<br />
{{hc|# dmesg {{!}} grep -i secure|<br />
[ 0.013442] Secure boot disabled<br />
[ 0.013442] Secure boot could not be determined<br />
}}<br />
<br />
The kernel messages will otherwise read {{ic|Secure boot enabled}}.<br />
<br />
== Booting an installation medium ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disabling Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.<br />
<br />
[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] images provide a way to use secure boot on installation media.<br />
<br />
=== Disabling 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 [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
=== Remastering the installation image ===<br />
<br />
{{Expansion|Add explicit instructions.}}<br />
<br />
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. Another option would be to borrow the {{ic|BOOTx64.EFI}} (shim) and {{ic|grubx64.efi}} from installation media of another GNU+Linux distribution that supports Secure Boot and modify the GRUB configuration to one's needs. In this case, the authentication chain of Secure Boot in said distribution's installation media should end to the {{ic|grubx64.efi}} ( [https://www.linux-magazine.com/index.php/layout/set/print/Issues/2014/164/The-State-of-Secure-Boot/(tagid)/154 for example Ubuntu]) so that GRUB would boot the unsigned kernel and initramfs from archiso. 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 />
== Implementing Secure Boot ==<br />
<br />
There are certain conditions making for an ideal setup of ''Secure boot'':<br />
<br />
# UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]]<br />
# Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/]<br />
# UEFI directly loads a user-signed [[EFISTUB]] combined kernel image (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface<br />
# Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.<br />
# Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement.<br />
<br />
A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party.<br />
<br />
=== Using your own keys ===<br />
<br />
{{Warning|Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware ([[Wikipedia:OpROM|OpROMs]]), that get executed during boot, are signed using [[#Microsoft Windows|Microsoft's key]].}}<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 denylisted 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 />
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 />
==== Install efitools ====<br />
<br />
Nearly all of the following sections require you to [[install]] the {{Pkg|efitools}} package.<br />
<br />
==== Backing up current variables ====<br />
<br />
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error.<br />
<br />
Run the following commands to backup all four of the principal Secure Boot variables:<br />
<br />
$ efi-readvar -v PK -o old_PK.esl<br />
$ efi-readvar -v KEK -o old_KEK.esl<br />
$ efi-readvar -v db -o old_db.esl<br />
$ efi-readvar -v dbx -o old_dbx.esl<br />
<br />
If you perform these commands on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft.<br />
<br />
==== Creating keys ====<br />
<br />
===== Manual process =====<br />
<br />
To generate keys, perform the following steps.<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 {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware.<br />
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and 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 />
===== Helper scripts =====<br />
<br />
A helper/convenience script is offered by the author of the reference page on this topic[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys] (requires [[python]]). A mildly edited version is also packaged as {{AUR|sbkeys}}.<br />
<br />
In order to use it, simply create a folder in a secure location (e.g. {{ic|/etc/efi-keys/}} if later use of {{AUR|sbupdate-git}} to automate unified kernel image creation and signing is planned) and run it:<br />
<br />
# mkdir /etc/efi-keys<br />
# cd !$<br />
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh<br />
# chmod +x mkkeys.sh<br />
# ./mkkeys.sh<br />
<Enter a Common Name to embed in the keys, e.g. "Secure Boot"><br />
<br />
This will produce the required files in different formats.<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, [[#Enrolling keys in firmware|enroll it]].<br />
<br />
==== Signing EFI binaries ====<br />
<br />
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched.<br />
<br />
===== Manually with sbsigntools =====<br />
<br />
Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}.<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* 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 />
<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 />
To sign your kernel and boot manager use ''sbsign'', e.g.:<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 />
{{Warning|Signing kernel only will not protect the initramfs from tampering. See [[Unified kernel image]] to know how to produce a combined image that you can then manually sign with ''sbsign''.}}<br />
<br />
===== Signing the kernel with a pacman hook =====<br />
<br />
You can also use mkinitcpio's [[pacman hook]] to sign the kernel on install and updates.<br />
<br />
Copy {{ic|/usr/share/libalpm/hooks/90-mkinitcpio-install.hook}} to {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}} and {{ic|/usr/share/libalpm/scripts/mkinitcpio-install}} to {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}.<br />
<br />
In {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}}, replace:<br />
<br />
Exec = /usr/share/libalpm/scripts/mkinitcpio-install<br />
<br />
with:<br />
<br />
Exec = /usr/local/share/libalpm/scripts/mkinitcpio-install<br />
<br />
In {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}, replace:<br />
<br />
install -Dm644 "${line}" "/boot/vmlinuz-${pkgbase}"<br />
<br />
with:<br />
<br />
sbsign --key ''/path/to/''db.key --cert ''/path/to/''db.crt --output "/boot/vmlinuz-${pkgbase}" "${line}"<br />
<br />
If you are using systemd-boot, there is a [[Systemd-boot#Automatic update|dedicated pacman hook]] doing this task semi-automatically.<br />
<br />
===== Fully automated unified kernel generation and signing with sbupdate =====<br />
<br />
[https://github.com/andreyv/sbupdate sbupdate] is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through [[pacman hooks]].<br />
<br />
Install {{AUR|sbupdate-git}} and configure it following the instructions given on the project's homepage.[https://github.com/andreyv/sbupdate#sbupdate]<br />
<br />
{{Tip|If using [[systemd-boot]], set {{ic|1=OUT_DIR="EFI/Linux"}} to get your signed kernel images directly recognized without needing configuration. See {{man|7|systemd-boot|FILES}} and [[Systemd-boot#Adding loaders]].}}<br />
<br />
Once configured, simply run {{ic|sbupdate}} as root for first-time image generation.<br />
<br />
{{Note|''sbupdate'' output often contains errors such as {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}}. Those are harmless and can be safely ignored.[https://github.com/andreyv/sbupdate/issues/30]}}<br />
<br />
==== Putting 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 />
==== Enrolling keys in firmware ====<br />
<br />
Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
{{Tip|As the '''dbx''' (forbidden signatures db) is empty, it can be safely left out in the following instructions.}}<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 sbkeysync =====<br />
<br />
Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure -<br />
<br />
/etc/secureboot/keys<br />
├── db<br />
├── dbx<br />
├── KEK<br />
└── PK<br />
<br />
For example using:<br />
<br />
# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}<br />
<br />
Then copy each of the ''.auth'' files that were generated earlier into their respective locations (for example, {{ic|PK.auth}} into {{ic|/etc/secureboot/keys/PK}} and so on).<br />
<br />
If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use:<br />
<br />
# sbkeysync --pk --dry-run --verbose<br />
<br />
Finally, use {{ic|sbkeysync}} to enroll your keys.<br />
<br />
# sbkeysync --verbose<br />
# sbkeysync --verbose --pk<br />
<br />
{{Tip|<br />
*If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}.<br />
* If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}.}}<br />
<br />
On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy.<br />
<br />
===== Using firmware setup utility =====<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files '''EXCEPT OF {{ic|noPK.auth}}''' files to a [[FAT]] formatted file system (you can use [[EFI system partition]]). <br />
<br />
{{Warning|'''Don't copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC!''' If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with his or her own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a safe place where only you have access to. A safe place for the noPK.auth file are: <br />
* an '''external USB stick with an [[EFI system partition]]''' when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage. <br />
* [[Data-at-rest encryption|encrypted storage on your PC]] when using {{ic|sbkeysync}}. <br />
The [[EFI system partition]] of your PC must not be encrypted according to the UEFI specifications and can be mounted and read on another PC (if your PC is stolen and if the hard drive is taken out and connected to another PC). Copying the {{ic|noPK.auth}} file to the ESP of your PC and deleting it afterwards is also not advisable, because deleted files on the FAT32 [[EFI system partition]] [[File recovery#TestDisk and PhotoRec|can be recovered with tools like PhotoRec]].}}<br />
<br />
Launch firmware setup utility and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
Firmwares have various different interfaces, see [https://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 />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<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 [https://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]]?|section=Booting Windows with custom bootloader signature}}<br />
<br />
It is usually '''not''' possible to boot Windows by signing its bootloader ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) with a [[#Creating keys|custom, personal key]] with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables: <br />
* if {{ic|bootmgfw.efi}} contains a signature '''both''' from the "Microsoft Windows Production PCA 2011" '''and''' from your own Secure Boot DB key (so '''two signatures'''), then UEFI firmware implementations like ''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' will not launch {{ic|bootmgfw.efi}} and will throw a security violation error ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}'''): UEFI firmware implementation like this can probably only read the '''first''' signature - not the '''second''' one. Only the certificate for the second signature is enrolled in the UEFI Secure Boot variables, so the Secure Boot verification fails. <br />
* if the "Microsoft Windows Production PCA 2011" signature from the {{ic|bootmgfw.efi}} file is stripped/removed, and only a signature from your own Secure Boot DB key is added to the file, then UEFI will launch the file - but Windows will launch a recovery/repair environment: Windows complains that the Windows installation is broken (because the "Microsoft Windows Production PCA 2011" signature on {{ic|bootmgfw.efi}} file is missing). <br />
<br />
So to [[dual boot with Windows]], ...<br />
* you either have to add the hash of {{ic|bootmgfw.efi}} to the list of allowed hashes in the {{ic|DB}} variable; and you have to update the {{ic|DB}} variable every time a Windows Update changes {{ic|bootmgfw.efi}}. This is very tedious, error-prone and not supported by Microsoft; and for example Bitlocker will not work properly anymore with this setup (Bitlocker will ask for your recovery password every time to decrypt your Windows partition). <br />
* or you have to add Microsoft's certificates to the UEFI Secure Boot variables [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has two {{ic|DB}} certificates and one {{ic|KEK}} certificate]:<br />
** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt "Microsoft Windows Production PCA 2011"] certificate must be included in the {{ic|DB}} variable in order to allow the Windows Operating System to load. <br />
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt "Microsoft Corporation UEFI CA 2011"] certificate should be included in the {{ic|DB}} variable in order to use third-party binaries like UEFI drivers, option ROMs, {{Pkg|shim}}, etc.<br />
** The [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt "Microsoft Corporation KEK CA 2011"] certificate should be included in the {{ic|KEK}} variable, in order to "enable revocation of bad images by updating the {{ic|DBX}} and potentially for updating {{ic|DB}} to prepare for newer Windows signed images". However, Windows will also boot without the "Microsoft Corporation KEK CA 2011" certificate. <br />
<br />
Create EFI Signature Lists from Microsoft's DER format {{ic|DB}} certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt<br />
$ cat MS_Win_db.esl MS_UEFI_db.esl > MS_db.esl<br />
<br />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format {{ic|KEK}} certificate using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}): <br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK.esl MicCorKEKCA2011_2011-06-24.crt <br />
<br />
Sign a {{ic|DB}} variable update with your {{ic|KEK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|DB}} certificate:<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 />
<br />
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Sign a {{ic|KEK}} variable update with your {{ic|PK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|KEK}} certificate: <br />
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth <br />
<br />
<br />
<br />
Follow [[#Enrolling keys in firmware]] to enroll {{ic|add_MS_db.auth}} and for strict conformity with Microsoft UEFI Secure Boot requirements {{ic|add_MS_Win_KEK.auth}} into the UEFI Secure Boot Database variables.<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 an allowlist called Machine Owner Key list, abbreviated MokList. 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 [[#Disabling Secure Boot]].}}<br />
<br />
===== Delete enrolled hash =====<br />
<br />
Every entry of hashes enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hashes to free the space and to prevent outdated programs from booting.<br />
<br />
[[Install]] {{Pkg|efitools}} and copy {{ic|KeyTool.efi}}:<br />
<br />
# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi<br />
<br />
Manage to boot to Preloader and you will see the KeyTool entry. You can then edit hashes in the MOK database.<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|<br />
* 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 />
* Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details.<br />
* It might be worth mentioning that if you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with {{ic|mokutil --disable-validation}}. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows with {{ic|chainloader}} in grub.<br />
}}<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 />
{{Note|<br />
* Make sure you do NOT copy fbx64.efi (which is under the same directory) unless you actually have a valid bootx64.csv to use. Otherwise shim will NOT execute grubx64.efi but will appear to fail to work and just reset the machine.<br />
}}<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 />
Finally, create a new NVRAM entry to boot {{ic|BOOTx64.EFI}}:<br />
<br />
# efibootmgr --verbose --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI<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 />
Target = linux-lts<br />
Target = linux-hardened<br />
Target = linux-zen<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 />
====== Shim with key and GRUB ======<br />
<br />
Complete the previous section first.<br />
<br />
Reinstall GRUB using {{ic|/usr/share/grub/sbat.csv}} with the {{ic|TPM}} module enabled and sign it:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules="tpm" --sbat /usr/share/grub/sbat.csv<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
# cp ''esp''/GRUB/grubx64.efi ''esp''/boot/grubx64.efi<br />
<br />
Reboot, select the key in ''MokManager'', and secureboot should be working.<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 />
== Protecting Secure Boot ==<br />
<br />
The only way to prevent anyone with physical access to disable Secure Boot is to protect the firmware settings with a password.<br />
<br />
Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.<br />
<br />
== See also ==<br />
<br />
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure boot]]<br />
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [https://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://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]<br />
* [http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]<br />
* National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]<br />
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr<br />
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)<br />
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)<br />
* [http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] by Lennart Poettering (2021-09-23)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface/Secure_Boot&diff=739944Unified Extensible Firmware Interface/Secure Boot2022-08-03T14:20:16Z<p>DasMenschy: /* Using firmware setup utility */ Don't copy noPK.auth to an easily accessible filesystem like the PC ESP, where it can be used by a laptop thief to replace your Secure Boot keys with his or her own Secure Boot keys.</p>
<hr />
<div>[[Category:Boot process]]<br />
[[ja:セキュアブート]]<br />
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Security}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Unified_Extensible_Firmware_Interface#Secure_boot|Secure Boot]] is a security feature found in the [[UEFI]] standard, designed to add a layer of protection to the [[Arch boot process|pre-boot process]]: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.<br />
<br />
As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|cover]], while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and [[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|cons]].<br />
<br />
{{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article and [[#See also|other online resources]]. This article focuses on how to set up Secure Boot in Arch Linux.}}<br />
<br />
== Checking Secure Boot status ==<br />
<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 />
<br />
An easy way to check Secure Boot status on systems using [[systemd]] is to use [[systemd-boot]]:<br />
<br />
{{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}}<br />
<br />
{{bc|$ bootctl status<br />
System:<br />
Firmware: UEFI 2.70 (American Megatrends 5.15)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
Boot into FW: supported<br />
...}}<br />
<br />
Here we see that Secure Boot is enabled and enforced; other values are {{ic|disabled}} for Secure Boot and {{ic|setup}} for Setup Mode[https://github.com/systemd/systemd/issues/8154#issue-296106251].<br />
<br />
{{Accuracy|This command might display more than five digits even though secure boot is enabled.}}<br />
<br />
Another way to check whether the machine was booted with Secure Boot is to use this command:<br />
<br />
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<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 />
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:<br />
<br />
{{hc|# dmesg {{!}} grep -i secure|<br />
[ 0.013442] Secure boot disabled<br />
[ 0.013442] Secure boot could not be determined<br />
}}<br />
<br />
The kernel messages will otherwise read {{ic|Secure boot enabled}}.<br />
<br />
== Booting an installation medium ==<br />
<br />
{{Note|The official installation image does not support Secure Boot ({{Bug|53864}}). To successfully boot the installation medium you will need to [[#Disabling Secure Boot|disable Secure Boot]].}}<br />
<br />
Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.<br />
<br />
[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] images provide a way to use secure boot on installation media.<br />
<br />
=== Disabling 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 [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot].<br />
<br />
=== Remastering the installation image ===<br />
<br />
{{Expansion|Add explicit instructions.}}<br />
<br />
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. Another option would be to borrow the {{ic|BOOTx64.EFI}} (shim) and {{ic|grubx64.efi}} from installation media of another GNU+Linux distribution that supports Secure Boot and modify the GRUB configuration to one's needs. In this case, the authentication chain of Secure Boot in said distribution's installation media should end to the {{ic|grubx64.efi}} ( [https://www.linux-magazine.com/index.php/layout/set/print/Issues/2014/164/The-State-of-Secure-Boot/(tagid)/154 for example Ubuntu]) so that GRUB would boot the unsigned kernel and initramfs from archiso. 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 />
== Implementing Secure Boot ==<br />
<br />
There are certain conditions making for an ideal setup of ''Secure boot'':<br />
<br />
# UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]]<br />
# Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/]<br />
# UEFI directly loads a user-signed [[EFISTUB]] combined kernel image (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface<br />
# Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.<br />
# Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement.<br />
<br />
A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party.<br />
<br />
=== Using your own keys ===<br />
<br />
{{Warning|Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware ([[Wikipedia:OpROM|OpROMs]]), that get executed during boot, are signed using [[#Microsoft Windows|Microsoft's key]].}}<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 denylisted 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 />
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 />
==== Install efitools ====<br />
<br />
Nearly all of the following sections require you to [[install]] the {{Pkg|efitools}} package.<br />
<br />
==== Backing up current variables ====<br />
<br />
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error.<br />
<br />
Run the following commands to backup all four of the principal Secure Boot variables:<br />
<br />
$ efi-readvar -v PK -o old_PK.esl<br />
$ efi-readvar -v KEK -o old_KEK.esl<br />
$ efi-readvar -v db -o old_db.esl<br />
$ efi-readvar -v dbx -o old_dbx.esl<br />
<br />
If you perform these commands on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft.<br />
<br />
==== Creating keys ====<br />
<br />
===== Manual process =====<br />
<br />
To generate keys, perform the following steps.<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 {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}.<br />
; ''.cer'': DER format certificates for firmware.<br />
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware.<br />
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and 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 />
===== Helper scripts =====<br />
<br />
A helper/convenience script is offered by the author of the reference page on this topic[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys] (requires [[python]]). A mildly edited version is also packaged as {{AUR|sbkeys}}.<br />
<br />
In order to use it, simply create a folder in a secure location (e.g. {{ic|/etc/efi-keys/}} if later use of {{AUR|sbupdate-git}} to automate unified kernel image creation and signing is planned) and run it:<br />
<br />
# mkdir /etc/efi-keys<br />
# cd !$<br />
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh<br />
# chmod +x mkkeys.sh<br />
# ./mkkeys.sh<br />
<Enter a Common Name to embed in the keys, e.g. "Secure Boot"><br />
<br />
This will produce the required files in different formats.<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, [[#Enrolling keys in firmware|enroll it]].<br />
<br />
==== Signing EFI binaries ====<br />
<br />
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched.<br />
<br />
===== Manually with sbsigntools =====<br />
<br />
Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}.<br />
<br />
{{Tip|<br />
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}.<br />
* 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 />
<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 />
To sign your kernel and boot manager use ''sbsign'', e.g.:<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 />
{{Warning|Signing kernel only will not protect the initramfs from tampering. See [[Unified kernel image]] to know how to produce a combined image that you can then manually sign with ''sbsign''.}}<br />
<br />
===== Signing the kernel with a pacman hook =====<br />
<br />
You can also use mkinitcpio's [[pacman hook]] to sign the kernel on install and updates.<br />
<br />
Copy {{ic|/usr/share/libalpm/hooks/90-mkinitcpio-install.hook}} to {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}} and {{ic|/usr/share/libalpm/scripts/mkinitcpio-install}} to {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}.<br />
<br />
In {{ic|/etc/pacman.d/hooks/90-mkinitcpio-install.hook}}, replace:<br />
<br />
Exec = /usr/share/libalpm/scripts/mkinitcpio-install<br />
<br />
with:<br />
<br />
Exec = /usr/local/share/libalpm/scripts/mkinitcpio-install<br />
<br />
In {{ic|/usr/local/share/libalpm/scripts/mkinitcpio-install}}, replace:<br />
<br />
install -Dm644 "${line}" "/boot/vmlinuz-${pkgbase}"<br />
<br />
with:<br />
<br />
sbsign --key ''/path/to/''db.key --cert ''/path/to/''db.crt --output "/boot/vmlinuz-${pkgbase}" "${line}"<br />
<br />
If you are using systemd-boot, there is a [[Systemd-boot#Automatic update|dedicated pacman hook]] doing this task semi-automatically.<br />
<br />
===== Fully automated unified kernel generation and signing with sbupdate =====<br />
<br />
[https://github.com/andreyv/sbupdate sbupdate] is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through [[pacman hooks]].<br />
<br />
Install {{AUR|sbupdate-git}} and configure it following the instructions given on the project's homepage.[https://github.com/andreyv/sbupdate#sbupdate]<br />
<br />
{{Tip|If using [[systemd-boot]], set {{ic|1=OUT_DIR="EFI/Linux"}} to get your signed kernel images directly recognized without needing configuration. See {{man|7|systemd-boot|FILES}} and [[Systemd-boot#Adding loaders]].}}<br />
<br />
Once configured, simply run {{ic|sbupdate}} as root for first-time image generation.<br />
<br />
{{Note|''sbupdate'' output often contains errors such as {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}}. Those are harmless and can be safely ignored.[https://github.com/andreyv/sbupdate/issues/30]}}<br />
<br />
==== Putting 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 />
==== Enrolling keys in firmware ====<br />
<br />
Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
<br />
{{Tip|As the '''dbx''' (forbidden signatures db) is empty, it can be safely left out in the following instructions.}}<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 sbkeysync =====<br />
<br />
Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure -<br />
<br />
/etc/secureboot/keys<br />
├── db<br />
├── dbx<br />
├── KEK<br />
└── PK<br />
<br />
For example using:<br />
<br />
# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}<br />
<br />
Then copy each of the ''.auth'' files that were generated earlier into their respective locations (for example, {{ic|PK.auth}} into {{ic|/etc/secureboot/keys/PK}} and so on).<br />
<br />
If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use:<br />
<br />
# sbkeysync --pk --dry-run --verbose<br />
<br />
Finally, use {{ic|sbkeysync}} to enroll your keys.<br />
<br />
# sbkeysync --verbose<br />
# sbkeysync --verbose --pk<br />
<br />
{{Tip|<br />
*If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}.<br />
* If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}.}}<br />
<br />
On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy.<br />
<br />
===== Using firmware setup utility =====<br />
<br />
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files '''EXCEPT OF {{ic|noPK.auth}}''' files to a [[FAT]] formatted file system (you can use [[EFI system partition]]). <br />
<br />
{{Warning|'''Don't copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC!''' If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with his or her own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a safe place where only you have access to. A safe place for the noPK.auth file are: <br />
* an '''external USB stick with an [[EFI system partition]]''' when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage. <br />
* [[Data-at-rest encryption|encrypted storage on your PC]] when using {{ic|sbkeysync}}. <br />
The [[EFI system partition]] of your PC must not be encrypted according to the UEFI specifications and can be mounted and read on another PC (if your PC is stolen and if the hard drive is taken out and connected to another PC). Copying the {{ic|noPK.auth}} file to the ESP of your PC and deleting it afterwards is also not advisable, because deleted files on the FAT32 [[EFI system partition]] [[File recovery#TestDisk and PhotoRec|can be recovered with tools like PhotoRec]].}}<br />
<br />
Launch firmware setup utility and enroll '''db''', '''KEK''' and '''PK''' certificates.<br />
Firmwares have various different interfaces, see [https://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 />
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''.<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 [https://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]]?|section=Booting Windows with custom bootloader signature}}<br />
<br />
To [[dual boot with Windows]], you would need to add Microsoft's certificates to the Signature Database. [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx 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 />
Create EFI Signature Lists from Microsoft's DER format certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity:<br />
<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db.esl MicWinProPCA2011_2011-10-19.crt<br />
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db.esl MicCorUEFCA2011_2011-06-27.crt<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 [[#Enrolling keys in firmware]] to add {{ic|add_MS_db.auth}} to Signature Database.<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 an allowlist called Machine Owner Key list, abbreviated MokList. 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 [[#Disabling Secure Boot]].}}<br />
<br />
===== Delete enrolled hash =====<br />
<br />
Every entry of hashes enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hashes to free the space and to prevent outdated programs from booting.<br />
<br />
[[Install]] {{Pkg|efitools}} and copy {{ic|KeyTool.efi}}:<br />
<br />
# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi<br />
<br />
Manage to boot to Preloader and you will see the KeyTool entry. You can then edit hashes in the MOK database.<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|<br />
* 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 />
* Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details.<br />
* It might be worth mentioning that if you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with {{ic|mokutil --disable-validation}}. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows with {{ic|chainloader}} in grub.<br />
}}<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 />
{{Note|<br />
* Make sure you do NOT copy fbx64.efi (which is under the same directory) unless you actually have a valid bootx64.csv to use. Otherwise shim will NOT execute grubx64.efi but will appear to fail to work and just reset the machine.<br />
}}<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 />
Finally, create a new NVRAM entry to boot {{ic|BOOTx64.EFI}}:<br />
<br />
# efibootmgr --verbose --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI<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 />
Target = linux-lts<br />
Target = linux-hardened<br />
Target = linux-zen<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 />
====== Shim with key and GRUB ======<br />
<br />
Complete the previous section first.<br />
<br />
Reinstall GRUB using {{ic|/usr/share/grub/sbat.csv}} with the {{ic|TPM}} module enabled and sign it:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules="tpm" --sbat /usr/share/grub/sbat.csv<br />
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
# cp ''esp''/GRUB/grubx64.efi ''esp''/boot/grubx64.efi<br />
<br />
Reboot, select the key in ''MokManager'', and secureboot should be working.<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 />
== Protecting Secure Boot ==<br />
<br />
The only way to prevent anyone with physical access to disable Secure Boot is to protect the firmware settings with a password.<br />
<br />
Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.<br />
<br />
== See also ==<br />
<br />
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore<br />
* [[Wikipedia:Unified Extensible Firmware Interface#Secure boot]]<br />
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith<br />
* [https://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://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial]<br />
* [http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]<br />
* National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]<br />
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr<br />
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)<br />
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)<br />
* [http://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] by Lennart Poettering (2021-09-23)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=707024Talk:Unified Extensible Firmware Interface/Secure Boot2021-12-21T21:40:37Z<p>DasMenschy: /* Booting Windows with custom bootloader signature */ delete leftover deprecated bootmgr.efi reference</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=707023Talk:Unified Extensible Firmware Interface/Secure Boot2021-12-21T21:37:45Z<p>DasMenschy: /* Booting Windows with custom bootloader signature */ fix formatting and delete leftover bootmgr.efi references</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via {{ic|bootmgfw}}, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi/ bootmgr.efi . <br />
My signature on bootmgfw.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''MicWinProPCA2011_2011-10-19.crt''' ]) into the UEFI Secure Boot {{ic|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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''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. <br />
::Currently, I am working around it by only enrolling the '''hashes of {{ic|bootmgfw.efi}}''' into the {{ic|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 {{ic|bootmgfw.efi}} changes because of a Windows 10 update, I also have to update the {{ic|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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=707022Talk:Unified Extensible Firmware Interface/Secure Boot2021-12-21T21:32:30Z<p>DasMenschy: /* Booting Windows with custom bootloader signature */ Add answer, remove unimportant bootmgr.efi stuff (only applies to old BIOS, not new UEFI)</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
:You may have two ESP partitions. Do you have multiple SecureBoot* entries in efivars? They have a GUID at the end which shows up in the bootctl listing. [[User:Gerdesj|Gerdesj]] ([[User talk:Gerdesj|talk]]) 09:54, 5 October 2021 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via bootmgfw/bootmgr, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi/ bootmgr.efi . <br />
My signature on bootmgfw.efi / bootmgr.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
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). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC)<br />
: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 {{ic|db}} variable)?<br />
:''(By the way, please [[Help:Editing#Indenting|indent]] your replies next time. It would be easier for people to separate out messages.)''<br />
:[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 15:39, 21 December 2021 (UTC)<br />
::Yes, if I enroll the Microsoft Windows Production UEFI DB signature CA key from 2011 ([https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt '''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 [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/ '''BOOTHOLE'''], which were introduced because Microsoft signs almost anything (probably including '''government surveillance tools'''). <br />
::As far as I know, Microsoft doesn't really check the programs it signs for security vulnerabilities. <br />
::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. [[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 21:32, 21 December 2021 (UTC)<br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)<br />
<br />
== Simplify the page by removing old instructions ==<br />
<br />
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? [[User:Foonoxous|Foonoxous]] ([[User talk:Foonoxous|talk]]) 15:16, 27 November 2021 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=User:DasMenschy&diff=697377User:DasMenschy2021-09-25T09:18:13Z<p>DasMenschy: Created page with "Hello, this is my user page. Add a section if you have a question!"</p>
<hr />
<div>Hello, this is my user page. Add a section if you have a question!</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=696973Talk:Unified Extensible Firmware Interface/Secure Boot2021-09-21T17:10:36Z<p>DasMenschy: fix formatting and add BIOS UEFI version</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via bootmgfw/bootmgr, signed with <br/><br />
- '''both''' Microsofts key <br/><br />
- '''and''' my personal key, <br/><br />
- in SecureBoot mode '''enabled''', <br/><br />
- with my '''personal''' SecureBoot keys enrolled in NVRAM; <br/> <br />
but somehow my BIOS gave a Secure Boot Violation error and didn't let me boot Windows: <br />
<br />
'''Selected boot image did not authenticate. Press ENTER to continue.'''<br />
<br />
It seems like my BIOS can '''only''' read the '''first''' signature of binary EFI files, '''not''' multiple signatures of bootmgfw.efi/ bootmgr.efi . <br />
My signature on bootmgfw.efi / bootmgr.efi was the '''second''' one; Microsofts signature was the '''first''' one: <br />
<br />
If I '''delete''' the Microsoft signature from bootmgfw.efi / bootmgr.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/bootmgr.efi is missing). <br />
<br />
My BIOS firmware: '''UEFI 2.31 (INSYDE Corp. 4096.01)''' <br />
<br />
My BIOS firmware in detail: <br />
$ sudo dmidecode -t bios<br />
# dmidecode 3.2<br />
Getting SMBIOS data from sysfs.<br />
SMBIOS 2.7 present.<br />
<br />
Handle 0x000E, DMI type 0, 24 bytes<br />
BIOS Information <br />
Vendor: Insyde<br />
Version: F.70<br />
Release Date: 07/18/2016<br />
Address: 0xE0000<br />
Runtime Size: 128 kB<br />
ROM Size: 4 MB<br />
Characteristics:<br />
PCI is supported<br />
BIOS is upgradeable<br />
BIOS shadowing is allowed<br />
Boot from CD is supported<br />
Selectable boot is supported<br />
EDD is supported<br />
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)<br />
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)<br />
5.25"/360 kB floppy services are supported (int 13h)<br />
5.25"/1.2 MB floppy services are supported (int 13h)<br />
3.5"/720 kB floppy services are supported (int 13h)<br />
3.5"/2.88 MB floppy services are supported (int 13h)<br />
8042 keyboard services are supported (int 9h)<br />
CGA/mono video services are supported (int 10h)<br />
ACPI is supported<br />
USB legacy is supported<br />
BIOS boot specification is supported<br />
Targeted content distribution is supported<br />
UEFI is supported<br />
BIOS Revision: 15.112<br />
Firmware Revision: 29.66<br />
<br />
<br />
So I suppose my UEFI/BIOS implementation is broken. '''My BIOS can probably only read the first signature of signed binary EFI files.''' <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgr.efi.signed bootmgr.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgr.efi bootmgr.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
$ mv bootmgr.efi.signed bootmgr.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ sbverify --list bootmgr.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgr.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC) <br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)</div>DasMenschyhttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface/Secure_Boot&diff=696971Talk:Unified Extensible Firmware Interface/Secure Boot2021-09-21T16:49:55Z<p>DasMenschy: add section on signing Microsoft Windows bootmgfw.efi / bootmgr.efi</p>
<hr />
<div>== Enroll hash file name ==<br />
<br />
I am a bit confused regarding the following lines:<br />
<br />
''* In the HashTool main menu, select {{ic|Enroll Hash}}, choose {{ic|\loader.efi}} and confirm with {{ic|Yes}}. Again, select {{ic|Enroll Hash}} and {{ic|archiso}} to enter the archiso directory, then select {{ic|vmlinuz-efi}} and confirm with {{ic|Yes}}. Then choose {{ic|Exit}} to return to the boot device selection menu.<br />
* In the boot device selection menu choose {{ic|Arch Linux archiso x86_64 UEFI CD}}''<br />
<br />
There is no file vmlinuz-efi in the said directory, there is only efiboot.img.<br />
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. --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 09:03, 5 February 2015 (UTC)<br />
<br />
: 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 [[Secure Boot#Disable Secure Boot|disable secure boot]] altogether. I think one is expected to integrate the outline in [[Secure Boot#Booting archiso|booting archiso]] with one of the approaches suggested by the rest of the article. For example, the [[Secure Boot#Set up PreLoader|Set up PreLoader section]] explicitly states the usefulness of {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} in {{Pkg|efitools}} is limited. But it also suggest how to get along with {{ic|PreLoader.efi}} and {{ic|HashTool.efi}} from {{AUR|preloader-signed}} or to [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ download them manually without using the AUR]. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 02:05, 18 December 2018 (UTC)<br />
<br />
::The comment you're replying to is from a time when the Archiso supported Secure Boot. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:34, 18 December 2018 (UTC)<br />
:::# Why, and when, support for secure boot removed from Archiso?<br />
:::# 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 [[Secure Boot#Booting archiso|booting archiso]] section should be moved to the section that is prior to [[Secure Boot#See also|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.<br />
::: [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:59, 18 December 2018 (UTC)<br />
<br />
::::As it says in [[Secure Boot#Booting archiso]], Secure Boot support was removed starting with {{ic|archlinux-2016.06.01-dual.iso}}. It happened because an Arch developer replaced[https://github.com/archlinux/svntogit-packages/commit/a9a9be60696a718f0aa1865d8c6663b2c2cdfce1][https://github.com/archlinux/svntogit-packages/commit/1b7b157c4f2dd062dcf00a589da37390e6a7b59d] the [https://github.com/archlinux/svntogit-packages/blob/packages/prebootloader/trunk/PKGBUILD prebootloader package] with the {{Pkg|efitools}} package. Apparently it happened because both contain {{ic|PreLoader.efi}} and {{ic|HashTool.efi}}. The ''little detail'' that one had signed EFI binaries, but other unsigned was somehow missed and the change got into Archiso[https://gitlab.archlinux.org/archlinux/archiso/commit/908370a17e6f9e64b38e9763db9357f0020ed1d9]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:15, 18 December 2018 (UTC)<br />
<br />
::::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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:18, 18 December 2018 (UTC)<br />
<br />
:::::+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. -- [[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:31, 18 December 2018 (UTC)<br />
<br />
:::::: I have edited the article to address [[User:Indigo|Indigo]] comment. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 11:43, 19 December 2018 (UTC)<br />
<br />
:::::::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 [https://wiki.archlinux.org/index.php?title=Secure_Boot&type=revision&diff=559612&oldid=559611] (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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:15, 20 December 2018 (UTC)<br />
<br />
== shim ==<br />
<br />
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.".<br />
<br />
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 {{ic|refind-install --shim /usr/share/shim-signed/shim.efi}} for hash only and {{ic|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. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 7 December 2016 (UTC)<br />
<br />
: A commented but complete and brief working bash-script that runs a signed Arch-Kernel via refind.efi would be nice. [[User:UBF6|UBF6]] ([[User talk:UBF6|talk]]) 14:40, 8 November 2018 (UTC)<br />
<br />
== add section explaining the signing of other EFI utilities, or general troubleshooting section ==<br />
<br />
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<br />
<br />
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 {{ic|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 {{ic|sbattach --remove gdisk_x64.efi}} I was finally able to get it to run with Secure Boot enabled.<br />
<br />
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.<br />
<br />
--[[User:AaronM_Cloudtek|AaronM_Cloudtek]] ([[User talk:AaronM_Cloudtek|talk]]) 05:31, 25 March 2019 (UTC)<br />
<br />
: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).<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:32, 24 December 2019 (UTC)<br />
<br />
== SBUpdate Behaviour Update ==<br />
<br />
"sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB."<br />
<br />
This is outdated. Uppercase and lowercase "db file" name is accepted. Script uses: @(DB|db)<br />
<br />
{{Unsigned|23:08, 2 July 2019 (UTC)|Superherointj}}<br />
<br />
:Feel free to remove that note. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:14, 3 July 2019 (UTC)<br />
<br />
== Booting with own keys but without Microsoft's keys ==<br />
<br />
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:<br />
<br />
: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.<br />
::— [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Rod Smith's Controlling Secure Boot]<br />
<br />
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.<br />
<br />
{{unsigned|07:09, 10 December 2019|Palimpseste}}<br />
<br />
: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 [[https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot 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.<br />
:[[User:Soroshi|Soroshi]] ([[User talk:Soroshi|talk]]) 20:24, 24 December 2019 (UTC)<br />
<br />
== Accuracy of "od" command to determine status ==<br />
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.<br />
This is what I got: <br />
<br />
~ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot*<br />
6 0 0 0 1 7 0 0 0 3<br />
<br />
However, the wiki states:<br />
If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example: <br />
6 0 0 0 1<br />
<br />
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: <br />
<br />
~ bootctl status<br />
systemd-boot not installed in ESP.<br />
No default/fallback boot loader installed in ESP.<br />
System:<br />
Firmware: UEFI 2.70 (Dell 1.00)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
...<br />
<br />
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. [[User:LoNaAleim|LoNaAleim]] ([[User talk:LoNaAleim|talk]]) 19:48, 24 August 2020 (UTC)<br />
<br />
== Booting Windows with custom bootloader signature ==<br />
<br />
Windows 10 '''can''' boot with custom bootloader signature. I signed {{ic|bootmgfw.efi}} and Windows still works normally.<br />
<br />
$ sbverify --list /boot/EFI/Microsoft/Boot/bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=[redacted] - Secure Boot DB<br />
image signature certificates:<br />
- subject: /CN=[redacted] - Secure Boot DB<br />
issuer: /CN=[redacted] - Secure Boot DB<br />
<br />
I don't currently have any other keys enrolled, apart from mine.<br />
<br />
$ efi-readvar <br />
Variable PK, length 863<br />
PK: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot PK<br />
Issuer:<br />
CN=[redacted] - Secure Boot PK<br />
Variable KEK, length 865<br />
KEK: List 0, type X509<br />
Signature 0, size 837, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot KEK<br />
Issuer:<br />
CN=[redacted] - Secure Boot KEK<br />
Variable db, length 863<br />
db: List 0, type X509<br />
Signature 0, size 835, owner [redacted-2]<br />
Subject:<br />
CN=[redacted] - Secure Boot DB<br />
Issuer:<br />
CN=[redacted] - Secure Boot DB<br />
Variable dbx has no entries<br />
Variable MokList has no entries<br />
(fields replaced with {{ic|[redacted]}} have the same value; same goes for {{ic|[redacted-2]}})<br />
<br />
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?<br />
<br />
P/s : maybe a method to automatically sign updates from Microsoft?<br />
<br />
[[User:Cipher|Cipher]] ([[User talk:Cipher|talk]]) 04:59, 5 November 2020 (UTC)<br />
<br />
Hi [[User:Cipher|Cipher]]! I tried booting Windows via bootmgfw/bootmgr, signed with <br/><br />
- BOTH Microsofts key <br/><br />
- AND my personal key, <br/><br />
- in SecureBoot mode enabled, <br/><br />
- with my personal SecureBoot keys enrolled in firmware; <br/> <br />
but somehow rEFInd gave a SecureBootViolation error and didn't let me boot Windows. It seems like rEFInd / my BIOS can ONLY read the FIRST signature of binary EFI files, NOT multiple signatures of bootmgfw.efi/ bootmgr.efi . <br />
My signature on bootmgfw.efi / bootmgr.efi was the SECOND one; Microsofts signature was the FIRST: <br />
<br />
If I delete the Microsoft signature from bootmgfw.efi / bootmgr.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/bootmgr.efi is missing). <br />
<br />
My BIOS firmware: UEFI 2.31 (INSYDE Corp. 4096.01) <br />
<br />
So I suppose my UEFI/BIOS implementation is broken. It can probably ONLY read the first signature of signed EFI files. <br />
<br />
Here's my code: <br />
$ cd /esp/EFI/Microsoft/Boot <br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgfw.efi.signed bootmgfw.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootmgr.efi.signed bootmgr.efi <br />
Image was already signed; adding additional signature<br />
<br />
$ mv bootmgfw.efi bootmgfw.efi.backup <br />
$ mv bootmgr.efi bootmgr.efi.backup <br />
$ mv bootmgfw.efi.signed bootmgfw.efi <br />
$ mv bootmgr.efi.signed bootmgr.efi <br />
<br />
$ sbverify --list bootmgfw.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgfw.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ sbverify --list bootmgr.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootmgr.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
$ cd /esp/EFI/BOOT/<br />
$ sudo sbsign --key /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.key \<br />
--cert /run/media/<redacted>/KEYS+PASSWORDS/SECUREBOOTKEYS/HP-Pavilion-TS-15-Notebook-PC-N010SG/db/DB.crt \<br />
--output bootx64.efi.signed bootx64.efi<br />
<br />
$ mv bootx64.efi bootx64.efi.backup <br />
$ mv bootx64.efi.signed bootx64.efi <br />
<br />
$ sbverify --list bootx64.efi.backup <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
<br />
$ sbverify --list bootx64.efi <br />
signature 1<br />
image signature issuers:<br />
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
image signature certificates:<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Production PCA 2011<br />
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010<br />
signature 2<br />
image signature issuers:<br />
- /CN=<redacted> DB<br />
image signature certificates:<br />
- subject: /CN=<redacted> DB<br />
issuer: /CN=<redacted> DB<br />
<br />
I only have my personal keys in UEFI keystore (redacted is my real name / my UUID), none from Microsoft: <br />
$ efi-readvar <br />
Variable PK, length 843<br />
PK: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> PK<br />
Issuer:<br />
CN=<redacted> PK<br />
Variable KEK, length 845<br />
KEK: List 0, type X509<br />
Signature 0, size 817, owner <redacted><br />
Subject:<br />
CN=<redacted> KEK<br />
Issuer:<br />
CN=<redacted> KEK<br />
Variable db, length 843<br />
db: List 0, type X509<br />
Signature 0, size 815, owner <redacted><br />
Subject:<br />
CN=<redacted> DB<br />
Issuer:<br />
CN=<redacted> DB<br />
Variable dbx, length 76<br />
dbx: List 0, type SHA256<br />
Signature 0, size 48, owner 00000000-0000-0000-0000-000000000000<br />
Hash:0000000000000000000000000000000000000000000000000000000000000000<br />
<br />
I have booted into SecureBootMode: <br />
$ bootctl status <br />
System:<br />
Firmware: UEFI 2.31 (INSYDE Corp. 4096.01)<br />
Secure Boot: enabled<br />
Setup Mode: user<br />
TPM2 Support: no<br />
Boot into FW: supported<br />
<br />
[[User:DasMenschy|DasMenschy]] ([[User talk:DasMenschy|talk]]) 16:49, 21 September 2021 (UTC) <br />
<br />
== Add a warning to warn users about dodgy firmware ==<br />
<br />
Unfortunately, as some of you may know, I bricked one of my motherboards with Secure Boot. This is partially documented [https://github.com/osresearch/safeboot/issues/84 in this issue].<br />
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. <br />
<br />
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.<br />
<br />
A very similar issue is apparently present in some Dell motherboards.<br />
<br />
Serious breakage (devices that do not POST anymore and similar) caused by modifications to the efivarfs, like accidentally removing {{ic|/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]].<br />
<br />
-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:51, 1 April 2021 (UTC)<br />
<br />
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.<br />
[[User:Tensa zangetsu|Tensa zangetsu]] ([[User talk:Tensa zangetsu|talk]]) 20:40, 15 May 2021 (UTC)</div>DasMenschy