Highly opinionated setup that provides minimal Secure Boot for Arch Linux, and a few recovery tools.
Bootloaders (such as GRUB or systemd-boot) are intentionally not supported, as they significantly increase the amount of code that runs during boot, therefore increasing the attack surface.
There are two key goals that motivated this project:
- Achieve encrypted
/bootwithout using GRUB (it is possible, contrary to popular belief) - Minimize amount of code that runs during boot (less code means less vulnerabilities to guard against)
Here's how it works:
-
Remove built-in Secure Boot keys, generate your own keys, leave private key on encrypted disk and register public key in BIOS
-
Keep
/booton encrypted disk, and mount unencrypted ESP FAT32 partition to/efi. -
Generate a new
.efifile that you will register in BIOS as boot target (i.e. instead ofgrub.efi), which consists of:- CPU microcode (
ucode.img) - initramfs
- vmlinuz
- hardcoded kernel cmdline (that specifies exact kernel arguments to boot, including root btrfs subvolume)
All of the above components are taken from the encrypted
/boot, so cannot be tampered with while the computer is turned off. - CPU microcode (
-
Sign this
.efifile with your own Secure Boot key and put this one file into unencrypted/efi. -
Configure in your BIOS that this is the boot target (instead of e.g. GRUB)
Now evil-maid attack is not possible, because the only unencrypted file is your signed .efi file, and if it is being tampered with, Secure Boot will refuse to load it.
Because cmdline is hardcoded in the image, Secure Boot also guarantees that you or attackers cannot just change it (e.g. to boot in an old subvolume).
In addition, because there is less steps in the process, and especially because you aren't decrypting your disk twice (like it is the case with GRUB), the boot is so much faster!
This project automates everything above, and adds a few other integrations that I personally use:
- pacman hooks (similar to
snap-pac-grub, so I can enable the tool and forget about it) - integration with
fwupd - custom EFI shell (because at least Dell's built-in implementation was quite buggy at the time of creating the project)
- a simple script that provides UI for selecting snapshot to boot into (inspired by
grub-btrfs)
The package is available on AUR: arch-secure-boot
See the available configuration options in the top of the script.
Add your overrides to /etc/arch-secure-boot/config.
Most notably, set KERNEL=linux-hardened if you use hardened Linux.
- BIOS: Set admin password, disable Secure Boot, delete all Secure Boot keys
- Run
arch-secure-boot initial-setupcommand, which:- Generates and enrolls keys
- Generates EFI images and adds the main one to UEFI (it's important, only the main one!)
- BIOS: Enable Secure Boot
Note: If you want to preserve Microsoft Secure-Boot keys, don't use the initial-setup command above as will replace them. Instead, look in the source code to see which commands initial-setup executes and run them by hand, replacing enroll-keys entirely with sbctl enroll-keys -m. This hasn't been tested, but is assumed to work (see #31).
If enrolling keys via initial-setup does not work, it might be caused by a bad implementation of UEFI by the manufacturer. In this case, you can try to go to UEFI, enable Setup Mode and enroll the keys from the GUI. Follow Arch wiki for some steps, and pay particular attention not to place Platform Key on the ESP partition, even temporarily!
When the system fails to boot, it is commonly caused by one of the two things:
- Something is wrong on the system (late boot), which might be resolved by booting in a btrfs snapshot.
- Something is wrong with the kernel (early boot), which might be resolved by booting in an LTS kernel.
That is why, in addition to generating the main image (which is added to your UEFI as boot target), this project generates two more .efi files:
-
One with:
- initramfs
- vmlinuz
- NO microcode (in case it causes boot failures)
- NO hardcoded cmdline (so that we can later select which subvolume to boot in)
-
Another just like the above, but with LTS kernel
These two are also signed with Secure Boot keys, but NOT added to UEFI boot targets.
- Attackers cannot use these
.efifiles because to boot into it they need to know your BIOS password. - Evil maid attack is not possible because this image is signed with Secure Boot keys and at no point in time do we disable Secure Boot.
- Because
cmdlineis NOT hardcoded in these recovery images, Secure Boot will let us specify a custom one - one where you specifyrootflags=subvol=snapshots/123/snapshotin order to boot into snapshot123.
In order to avoid typing a custom cmdline by hand, this project provides a simple recovery.nsh script that allows you to select a snapshot to boot into - DO inspect it before launching, as it is stored on unencrypted /efi partition when you need to use it.
- BIOS: use admin password to boot into
efi-shellimage - Inspect recovery script using
edit FS0:\recovery.nsh(ifFS0is not your hard disk, try otherFSn) - Run the script using
FS0:\recovery.nsh - Once recovered, remove
efi-shellentry from UEFI
arch-secure-boot initial-setupruns all the steps below in the proper orderarch-secure-boot generate-keysgenerates new keys for Secure Bootarch-secure-boot enroll-keysadds them to your UEFIarch-secure-boot generate-eficreates several images signed with Secure Boot keysarch-secure-boot add-efiadds UEFI entry for the main Secure Boot imagearch-secure-boot generate-snapshotsgenerates a list of btrfs snapshots for recovery
secure-boot-linux.efi- the main imagevmlinuz-linux+initramfs-linux+*-ucode+ hardcodedcmdline
secure-boot-linux-efi-shell.efi- UEFI shell that is used to boot into a snapshot- because built-in UEFI shells are known to be buggy
secure-boot-linux-recovery.efi- recovery image that can be a used to boot from snapshotvmlinuz-linux+initramfs-linux-fallback
secure-boot-linux-lts-recovery.efi- recovery LTS image that can be used to boot from snapshotvmlinuz-linux-lts+initramfs-linux-lts-fallback
fwupdx64.efi image is also being signed.