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
/boot
without 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
/boot
on encrypted disk, and mount unencrypted ESP FAT32 partition to/efi
. -
Generate a new
.efi
file 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
.efi
file 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-setup
command, 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
.efi
files 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
cmdline
is NOT hardcoded in these recovery images, Secure Boot will let us specify a custom one - one where you specifyrootflags=subvol=snapshots/123/snapshot
in 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-shell
image - Inspect recovery script using
edit FS0:\recovery.nsh
(ifFS0
is not your hard disk, try otherFSn
) - Run the script using
FS0:\recovery.nsh
- Once recovered, remove
efi-shell
entry from UEFI
arch-secure-boot initial-setup
runs all the steps below in the proper orderarch-secure-boot generate-keys
generates new keys for Secure Bootarch-secure-boot enroll-keys
adds them to your UEFIarch-secure-boot generate-efi
creates several images signed with Secure Boot keysarch-secure-boot add-efi
adds UEFI entry for the main Secure Boot imagearch-secure-boot generate-snapshots
generates 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.