Ticket: tails#6560 (closed)

• One possible plan
• Resources
• Automated testing

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 aufs module so we need to migrate to overlayfs (tails#8415 (closed)).
• overlayfs does not allow stacking enough layers for our current upgrade system, so we need to stack one single SquashFS diff when upgrading (tails#15281 (closed)).

Resources

• Debian's Secure Boot support will be done for GRUB first, unclear if other bootloaders will be supported
  • tracker bug: Debian bug #820036
  • shim is in Debian (signed by the Microsoft UEFI CA) but grub2-signed is not (RFP bug).
• How other distros do it:
  • Ubuntu
  • ArchLinux
  • Fedora
  • 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:
  • Handling UEFI Secure Boot in smaller distributions
  • Secure Boot bootloader for distributions available now
  • An overview of Fedora's Secure Boot implementation
  • Terse howto for getting a signed shim
• 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

Automated testing

• 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/OVMF/OVMF_VARS.ms.fd and /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 EnrollDefaultKeys.efi from OVMF.
• Automating Secure Boot Testing: how Red Hat does CI for Secure Boot (FOSDEM 2018)
• https://wiki.ubuntu.com/UEFI/SecureBoot/Testing
• https://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm
• https://fedoraproject.org/wiki/Using_UEFI_with_QEMU#Testing_Secureboot_in_a_VM
• https://github.com/puiterwijk/qemu-ovmf-secureboot