Ticket: tails#6560 (closed)
One possible plan
Goal: avoid the need to disable Secure Boot in the firmware configuration. Tails should boot out-of-the-box with Secure Boot enabled, without the user having to do anything special about it.
Means: use the shim signed by Microsoft + GRUB2.
We don't support booting on a custom built kernel, so that should be relatively easy. Except:
- The kernel won't allow loading an unsigned
aufsmodule so we need to migrate to
overlayfsdoes not allow stacking enough layers for our current upgrade system, so we need to stack one single SquashFS diff when upgrading (tails#15281 (closed)).
- Debian's Secure Boot support will be done for GRUB first, unclear if other bootloaders will be supported
- How other distros do it:
- ALT Linux' SecureBoot mini HOWTO and their scripts
- Ubuntu Privacy Remix's next release (UPR 12.04r1) will support UEFI; a beta is available; they copied the solution from Ubuntu 13.10 (beta): the shim bootloader and a corresponding GRUB binary which passes secure boot. See their build script.
- Matthew Garrett:
- Managing EFI Boot Loaders for Linux: Dealing with Secure Boot, by Rod Smith
- GRUB 2.04 will support UEFI Secure Boot (currently every distro has patches for that)
- Booting a Self-signed Linux Kernel, by Greg Kroah-Hartman
- Linux Foundation's Making UEFI Secure Boot Work With Open Platforms
- The hard(est) part seems to be about how to enroll the signing keys
into the nvram file.
ovmf 0.0~20200229-2 installs a "ms" firmware
descriptor, "which has keys pre-enrolled and Secure Boot enabled".
E.g. in the package there's
/usr/share/qemu/firmware/40-edk2-x86_64-secure-enrolled.json. There's probably a way to ask libvirt to instruct QEMU to use that.
- One option is to use
- ovmf 0.0~20200229-2 installs a "ms" firmware descriptor, "which has keys pre-enrolled and Secure Boot enabled". E.g. in the package there's
- Automating Secure Boot Testing: how Red Hat does CI for Secure Boot (FOSDEM 2018)