Project

General

Profile

Feature #6560

UEFI Secure boot

Added by intrigeri almost 6 years ago. Updated about 10 hours ago.

Status:
In Progress
Priority:
High
Assignee:
-
Category:
Hardware support
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
feature/6560-secure-boot
Type of work:
Code
Starter:
No
Affected tool:

Description

At some point, Tails will have to support UEFI Secure boot.

Team: FT


Subtasks

Bug #17352: Release alpha with Secure Boot, GRUB, and overlayfsConfirmedintrigeri


Related issues

Related to Tails - Feature #11679: Rethink the installation process and upgrade process Resolved 08/20/2016
Related to Tails - Bug #15016: Explain better how to disable Secure Boot Rejected 12/05/2017
Blocked by Tails - Feature #5739: Support UEFI boot Resolved 10/03/2013
Blocked by Tails - Feature #15292: Distribute a USB image Resolved 04/14/2016 01/29/2019
Blocked by Tails - Feature #15806: Use GRUB for USB boot on EFI 64-bit In Progress 08/18/2018
Blocked by Tails - Feature #8415: Migrate from aufs to overlayfs In Progress 12/18/2014
Blocked by Tails - Feature #15944: Port Tails to Buster Resolved 09/12/2018
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision 69157449 (diff)
Added by intrigeri 8 months ago

Use GRUB with Secure Boot support for x86_64 (refs: #6560, #15806)

Known limitations:

- Until Debian's shim-signed is signed by Microsoft, this will only
work after enrolling the Debian test signing key:
https://wiki.debian.org/SecureBoot/Testing
- Until we switch to overlayfs, this won't boot as the out-of-tree
aufs module is not signed and the kernel will thus refuse loading
it when Secure Boot is enabled (#8415).
- No signed EFI binaries for ia32: shim-signed is only built
for amd64 at the moment. Besides, grub-efi-ia32-signed is only
available in the i386 Debian archive (which could be solved
using APT's multiarch support).
This is out of scope for this project.
- Our design doc is outdated.
- The GRUB menu may be less user-friendly than the previous syslinux
one.
- No background image in the GRUB menu; however, note that we had to disable
the background image for syslinux in UEFI mode since it broke the bootloader
on some hardware.
- Our test suite relies on syslinux (images, keystrokes).

Revision 6b48783f (diff)
Added by intrigeri 8 months ago

Make GRUB configuration compatible with Debian's Secure Boot implementation (refs: #6560)

With Secure Boot enabled, we can't load the (unsigned) syslinuxcfg and cpuid
GRUB modules. So we need to write a self-sufficient GRUB configuration file
ourselves, instead of loading the syslinux one.

Also, drop one layer of indirection:

- use /EFI/debian/grub.cfg, which is loaded by default by the Debian-signed
GRUB EFI image
- install GRUB modules under /EFI/debian/grub, where the Debian-signed
GRUB EFI image look for them by default

This avoids having to write extra code that would locate the actual place where
the GRUB files, and set $root and $prefix accordingly, which might not even
possible to do without trusting all local partitions.

Accordingly, set prefix to /efi/debian/grub when generating the unsigned
GRUB image for 32-bit EFI.

Revision 3da2ff54 (diff)
Added by segfault 18 days ago

Display background image in GRUB (refs: #6560)

Revision 5d0ad3e4 (diff)
Added by segfault 18 days ago

Use the AMNESIA_APPEND variable in grub.cfg (refs: #6560)

Revision 4bf8cc24 (diff)
Added by segfault 18 days ago

Use a custom background image for GRUB (refs: #6560)

The syslinux boot menu is displayed in the center of the screen and in
the background image we use for syslinux, we put the Tails logo on the
left, so that it's displayed left of the boot menu.

The GRUB boot menu uses a bigger part of the screen. When using the same
background image as for syslinux, the logo looks out of place.

This adds a custom background image for GRUB, in which the logo is in
the center.

Revision 7a150c77 (diff)
Added by segfault 18 days ago

Set timeout for GRUB boot menu (refs: #6560)

To 4 seconds, same as for syslinux.

History

#1 Updated by intrigeri almost 6 years ago

  • Category set to Hardware support

#2 Updated by intrigeri almost 6 years ago

  • Priority changed from Normal to Low

#3 Updated by BitingBird over 5 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

There is a blueprint, so I change the status to "in progress"

#4 Updated by intrigeri over 5 years ago

  • Status changed from In Progress to Confirmed

BitingBird wrote:

There is a blueprint, so I change the status to "in progress"

Honestly, the blueprint is just a compilation of bookmarks we've collected in the last few years. We have no plan, no idea which one of the various main paths we'll pick, and nobody is actively working on it, nor has plans to do so. So, I don't think "In progress" reflects correctly the real state of this task, and I'd rather not see this indication discourage anyone from tackling it. (Oh, and next time you'll triage the "In progress without assignee" tickets, it would pop up on your radar again ;)

#5 Updated by zjaume over 2 years ago

Would this feature implemented? I think it's very anoying to disable Secure Boot on every PC when trying to boot tails.

#6 Updated by intrigeri almost 2 years ago

  • Related to Feature #11679: Rethink the installation process and upgrade process added

#7 Updated by intrigeri almost 2 years ago

#8 Updated by intrigeri over 1 year ago

  • Related to Bug #15016: Explain better how to disable Secure Boot added

#9 Updated by intrigeri over 1 year ago

It is now quite likely that Debian Buster will have Secure Boot support (see https://debconf18.debconf.org/talks/59-report-from-the-debian-efi-team-about-the-support-of-secure-boot-on-debian/ for the latest status update). According to the tracking bug, the only remaining blockers that matter for Tails are https://bugs.debian.org/821051 and https://bugs.debian.org/820050.

This will allow us to add such support to Tails, hopefully without too much trouble. We'll have to switch to GRUB2, at least for USB sticks; wrt. DVD boot, since the ISO will only be supported for VMs after #15292 is done, if it's cheaper the ISO can keep using isolinux and not support Secure Boot.

#10 Updated by intrigeri over 1 year ago

  • Blocked by Feature #15806: Use GRUB for USB boot on EFI 64-bit added

#11 Updated by intrigeri over 1 year ago

  • Description updated (diff)
  • Priority changed from Low to Normal
  • Target version set to 2019

#12 Updated by sajolida about 1 year ago

Someone is doing this already by patching an already-installed Tails:

https://mailman.boum.org/pipermail/tails-dev/2018-November/012354.html

Could we do this as well?

(Updated link to archive: https://lists.autistici.org/message/20181104.032028.086db28c.en.html — which mostly points to https://pav-computer-notes.blogspot.com/2017/10/patching-tails-usb-stick-for-uefi.html -- intrigeri)

#13 Updated by intrigeri about 1 year ago

Could we do this as well?

Replied on tails-dev. tl;dr: yes, if we postpone something else or find/hire more developers.

#14 Updated by sajolida about 1 year ago

My learning from https://mailman.boum.org/pipermail/tails-dev/2018-November/thread.html is that support for Secure Boot is not blocked by Debian 10 (Buster).

#15 Updated by beta-tester 12 months ago

intrigeri wrote:

At some point, Tails will have to support UEFI Secure boot.

Team: FT

please don't forget those people who has a tablet/netbook with 64bit CPU but UEFI 32bit. those can't be booted with a bootx64.efi file. they need a bootia32.efi. the only distribution that provides those capability at the moment is Fedora 29 Workstation Live (64bit).
and all bootia32.efi and bootx64.efi stuff there is "Microsoft Corporation UEFI CA" signed, to be able to UEFI boot with SecureBott enabled.
see also https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1793894

#16 Updated by intrigeri 12 months ago

please don't forget those people who has a tablet/netbook with 64bit CPU but UEFI 32bit.

We've supported these systems (with Secure Boot disabled) since Tails 1.5. I do hope we'll manage to add Secure Boot support for those too. Depending on how hard it is, we might or might not block on it.

#17 Updated by intrigeri 11 months ago

#18 Updated by intrigeri 11 months ago

Blocked by Feature #8415: Migrate from aufs to overlayfs added

Explanation: due to the lockdown patches, the kernel will refuse loading unsigned modules, such as the aufs module we're building ourselves. So this ticket is blocked by #8415, which is itself blocked by #15281. It might be that the dependency tree is larger, let's make sure we have it in mind if/when we prepare a grant proposal for Secure Boot.

#20 Updated by intrigeri 9 months ago

#21 Updated by intrigeri 8 months ago

#22 Updated by intrigeri 8 months ago

  • Status changed from Confirmed to In Progress

#23 Updated by intrigeri 8 months ago

  • Status changed from In Progress to Confirmed
  • Feature Branch set to wip/feature/6560-secure-boot

Got a PoC that boots fine until the kernel refuses to load the aufs module, on a system with Secure Boot enabled.

#24 Updated by intrigeri 3 months ago

  • Feature Branch changed from wip/feature/6560-secure-boot to feature/6560-secure-boot

#25 Updated by segfault 18 days ago

  • Status changed from Confirmed to In Progress

#26 Updated by intrigeri 15 days ago

  • Priority changed from Normal to High
  • Target version changed from 2019 to Tails_4.5

Some of this has to be done by May, some of it by July.

Also available in: Atom PDF