# Secure Boot This guide will show you how to set up UEFI Secure Boot with Arch Linux. Once finished, you will be left with a system that doesn't allow booting any untrusted EFI images (other operating systems, fraudulently modified kernels, ...) on your machine. This guide assumes you're following from the [INSTALLATION](./01_INSTALLATION.md) guide and that you're using [UNIFIED KERNEL IMAGES](./03_UNIFIED_KERNEL_IMAGES.md) (UKIs) for booting. ## Security requirements Meeting these requirements is optional, as it is possible to set up secure boot without them. That said, if you don't meet these, setting up secure boot will not be a very effective security measure and it might be more of a time waste than a helpful means of enhancing your security. First requirement is to set up a **BIOS Password**. This is a password that you will be asked for every time you wish to enter the BIOS (UEFI). This is necessary, as without it, an attacker could very easily just go to the BIOS and disable Secure Boot. The second requirement is having **disk encryption**, at least for the root partition. This is important, because the UEFI signing keys will be stored here, and you don't want someone to potentially be able to get access to them, as it would allow them to sign any malicious images, making them pass secure boot. > [!WARNING] > Even after following all of these, you should be aware that Secure Boot isn't > an unbreakable solution. In fact, if someone is able to get a hold of your > machine, they can simply pull out the CMOS battery, which usually resets the > UEFI. That means turning off Secure Boot, and getting rid of the BIOS > password. > > While Secure Boot is generally a good extra measure to have, it is by no means > a reliable way to completely prevent others from ever being able to boot > untrusted systems, unless you use a specialized motherboard, which persists > the UEFI state. ## Enter Setup mode To allow us to upload new signing keys into secure boot, we will need to enter "setup mode". This should be possible by going to the Secure Boot category in your UEFI settings, and clicking on Delete/Clear certificates, or there could even just be a "Setup Mode" option directly. Once enabled, save the changes and boot back into Arch linux. ```bash pacman -S sbctl sbctl status ``` Make sure that `sbctl` reports that Setup Mode is Enabled. ## Create Secure Boot keys We can now create our new signing keys for secure boot. These keys will be stored in `/usr/share/secureboot` (so in our encrypted root partition). Once created, we will add (enroll) these keys into the UEFI firmware (only possible when in setup mode) ```bash sbctl create-keys sbctl enroll-keys -m ``` > [!WARNING] > The `-m` option (also known as `--microsoft`) will make sure to also include > the Microsoft signing keys. This is required by most motherboards, not using > it could brick your device. > [!NOTE] > If you encounter "File is immutable" warnings after running sbctl, it should > be safe to simply add the `-i` (or `--ignore-immutable`) flag, which will run > `chattr` and remove the immutable flags from these files for you. > > You can also do so manually with `chattr -i [file]` for all the listed > immutable files and then re-run the enroll-keys command. > > This happens because the Linux kernel will sometimes mark the runtime EFI > files as immutable for security - to prevent bricking the device with just `rm -rf /*`, or similar stupid commands, however since we trust that `sbctl` will > work and won't do anything malicious, we can just remove the immutable flag, > and re-running will now work). > > If you still encounter errors even with this flag, it means you have probably > done something wrong when entering the setup mode. Try looking for a option > like "Reset keys" in your UEFI, then try this again. ## Sign the bootloader and Unified Kernel Images Finally then, we can sign the `.efi` executables that we'd like to use: ```bash sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi sbctl sign -s /efi/EFI/BOOT/BOOTX64.EFI sbctl sign -s /efi/EFI/systemd/systemd-bootx64.efi sbctl sign -s /efi/EFI/Linux/arch-linux.efi sbctl sign -s /efi/EFI/Linux/arch-linux-fallback.efi ``` (If you're booting directly from UKI images, only sign those - in `/efi/EFI/Linux`) The `-s` flag means save: The files will be automatically re-signed when we update the kernel (via a sbctl pacman hook). > [!TIP] > To make sure that this is the case, we can run `pacman -S linux` and check > that messages about image signing appear. > > They should look something like this: > > ```text > Signing /efi/EFI/Linux/arch-linux.efi > ✓ Signed /efi/EFI/Linux/arch-linux.efi > ... > Signing /efi/EFI/Linux/arch-linux-fallback.efi > ✓ Signed /efi/EFI/Linux/arch-linux-fallback.efi > ... > File has already been signed /efi/EFI/Linux/arch-linux-fallback.efi > File has already been signed /efi/EFI/Linux/arch-linux.efi > File has already been signed /efi/EFI/systemd/systemd-bootx64.efi > File has already been signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed > File has already been signed /efi/EFI/BOOT/BOOTX64.EFI > ``` When done, we can make sure that everything that needed to be signed really was signed with: ```bash sbctl verify ``` You can also check that setup mode got disabled after enrolling the keys: ```bash sbctl status ``` Setup mode status should now report as `Disabled`. (Secure boot will still not appear as enabled though.) ## Reboot with secure boot We should now be ready to enable secure boot, as our `.efi` images were signed, and the signing key was enrolled to UEFI firmware. So, all that remains is: ```bash reboot ``` Boot into UEFI, go to the Secure Boot settings and enable it. (It might get enabled automatically on some UEFI firmware after setup mode, but it's not always the case.) ### Verify it worked To make sure that it worked as expected, and you're booted with secure-boot enabled, you can now run: ```bash sbctl status ``` It should report `Secure Boot: enabled` or `Secure Boot: enabled (user)`. ## Why bother? As I mentioned, secure boot can be bypassed if someone tries hard enough (pulling the CMOS battery). That then brings to question whether it's even worth it to set it up, when it doesn't really give you that much. On its own, I probably wouldn't bother with setting up secure-boot, however secure boot allows me to set up TPM (Trusted Platform Module) to automatically release the decryption keys for my LUKS encrypted root partition, in a secure way. This means I won't have to type my disk password every time I boot which is actually the primary reason why I like having secure-boot enabled. For more information on this, check out the follow-up guide: [TPM_UNLOCKING](./06_TPM_UNLOCKING.md).