Project

General

Profile

Feature #15806

Feature #6560: UEFI Secure boot

Use GRUB for USB boot on EFI 64-bit

Added by intrigeri over 1 year ago. Updated 11 days ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
feature/6560-secure-boot+force-all-tests
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

We need this for Secure Boot (#6560) and it'll simplify quite a few parts of our code.

Making a Tails USB image boot with GRUB is straightforward but we need to:

  • Find another way to identify the boot device in our partitioning script: git grep -E 'FSUUID|sysappend'
  • Update our test suite accordingly: it currently expects the syslinux UI
  • Subtasks of this very issue
  • Fix whatever the tests below show as broken

Team: FT (intrigeri, segfault)

Manual testing plan

Note:

  • Tests done at 3c79a9cdbeb33d99a4cec7dc024091204b37db1a
  • Since this branch includes #8415, the upgrade tests below also cover switching from aufs to overlayfs.
  • Automatic upgrade tests are done like this:
    • IUK generated using wrap_tails_create_iuks (just like in our release process)
    • IUK installed manually with tails-install-iuk (UDFs are not impacted by this branch, only IUK generation is)

Freshly installed Tails built from this branch

First, boots using isolinux from DVD: OK

Second, USB tests:

  1. boot a USB stick that's been freshly installed from this branch
  2. verify that the system partition was resized
  3. boot a 2nd time to ensure that resizing the system partition did not break the boot
GNOME Disks (.img) Tails Installer (cloning) Etcher (.img)
boots using GRUB on EFI 64-bit + Secure Boot OK OK TODO
boots using GRUB on EFI 32-bit OK OK TODO
boots using syslinux on legacy BIOS OK OK TODO

Tails upgraded from older version that had no GRUB 64-bit EFI

with Tails Installer (cloning) with automatic upgrade
boots using GRUB on EFI 64-bit + Secure Boot OK OK
boots using GRUB on EFI 32-bit OK OK
boots using syslinux on legacy BIOS OK OK
syslinux EFI 64-bit was deleted OK OK

Tails upgraded from older Tails that already had GRUB 64-bit EFI

Note: the new image & the corresponding test IUK must modify EFI/debian/grub.cfg.

with Tails Installer (cloning) with automatic upgrade
boots using GRUB on EFI 64-bit + Secure Boot OK OK
boots using GRUB on EFI 32-bit OK OK
boots using syslinux on legacy BIOS OK OK
EFI/debian/grub.cfg was updated OK OK

Subtasks

Feature #17494: Update design doc for GRUB + Secure BootResolved


Related issues

Related to Tails - Feature #7422: Do not duplicate syslinux on the ISO root filesystem Rejected 06/19/2014
Related to Tails - Feature #15292: Distribute a USB image Resolved 04/14/2016 01/29/2019
Related to Tails - Feature #12440: Drop GRUB for 32-bit (ia32) UEFI Rejected 04/12/2017
Related to Tails - Feature #12439: Unify the syslinux directory & config file name between ISO and installed USB stick Rejected 04/12/2017
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed
Blocks Tails - Bug #16980: Increase size of random seed in the kernel command-line Confirmed
Blocks Tails - Bug #17049: Recent MacBook does not start: no boot menu, black screen Resolved

Associated revisions

Revision 69157449 (diff)
Added by intrigeri 12 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 99fd55d4 (diff)
Added by segfault 4 months ago

Add FSUUID to grub menu entry (refs: #15806)

Also adds a troubleshoot entry.

Revision 783874cd (diff)
Added by segfault 4 months ago

Install grub from sid (refs: #15806)

The grub version in sid supports the "probe" grub command, which allows
us to easily set the root filesystem's UUID on the kernel command-line.

Revision 9faa81c6 (diff)
Added by segfault about 1 month ago

Install grub from bullseye instead of sid (refs: #15806)

We need the probe command from 2.04, which is now also available in
bullseye.

See also 783874cd466f3b139950be8e090127e1f5d42464.

Revision fa2b9bd9 (diff)
Added by intrigeri about 1 month ago

Test suite: adjust UEFI test for GRUB (refs: #15806)

Revision fbc34abe (diff)
Added by intrigeri about 1 month ago

Upgrader: also delete files that were removed in EFI/debian (refs: #15806)

Otherwise, automatic upgrades would never delete anything in there.

Revision 3c79a9cd (diff)
Added by intrigeri about 1 month ago

Repair 32-bit EFI boot (refs: #15806)

It was broken while switching 64-bit EFI to GRUB.

Revision 7ca99d6f
Added by intrigeri 11 days ago

Merge branch 'feature/6560-secure-boot+force-all-tests' into devel (Closes: #6560, #8415, #15806, #17049)

History

#1 Updated by intrigeri over 1 year ago

#2 Updated by intrigeri over 1 year ago

  • Related to Feature #7422: Do not duplicate syslinux on the ISO root filesystem added

#3 Updated by intrigeri over 1 year ago

#4 Updated by intrigeri over 1 year ago

#5 Updated by intrigeri over 1 year ago

  • Related to Feature #12439: Unify the syslinux directory & config file name between ISO and installed USB stick added

#6 Updated by intrigeri over 1 year ago

We won't do this as part of the USB Image project.

#7 Updated by intrigeri over 1 year ago

  • Description updated (diff)
  • Target version set to 2019

#8 Updated by intrigeri 12 months ago

#9 Updated by intrigeri 12 months ago

  • Subject changed from Use GRUB for USB boot to Use GRUB for USB boot on EFI 64-bit
  • Description updated (diff)
  • Feature Branch set to wip/feature/6560-secure-boot

Clarifying the scope of this ticket; got a PoC that boots fine, documenting the next steps in the ticket description.

#10 Updated by intrigeri 12 months ago

  • Description updated (diff)

#11 Updated by intrigeri 12 months ago

  • Description updated (diff)

#12 Updated by intrigeri 12 months ago

  • Related to Bug #16229: Boot Loader Menu documentation does not support 32-bit UEFI added

#13 Updated by intrigeri 12 months ago

  • Status changed from Confirmed to In Progress

#14 Updated by intrigeri 12 months ago

  • Status changed from In Progress to Confirmed

#15 Updated by segfault 8 months ago

  • Blocks Bug #16980: Increase size of random seed in the kernel command-line added

#16 Updated by intrigeri 7 months ago

  • Related to Bug #17049: Recent MacBook does not start: no boot menu, black screen added

#17 Updated by intrigeri 7 months ago

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

#18 Updated by intrigeri 7 months ago

  • Related to deleted (Bug #17049: Recent MacBook does not start: no boot menu, black screen)

#19 Updated by intrigeri 7 months ago

  • Blocks Bug #17049: Recent MacBook does not start: no boot menu, black screen added

#20 Updated by intrigeri 6 months ago

Possibly relevant although we're using live-build 2.x and might just do our GRUB config stuff ourselves without live-build's help: https://bugs.debian.org/940846

#21 Updated by segfault 4 months ago

  • Find another way to identify the boot device in our partitioning

I can't find a way to make grub tell us the boot device. If we don't find an option for that, the only alternative I see is to do the same thing live-boot does to choose the boot device, which is trying to mount all removable devices and choose the first one that contains a squashfs (or other filesystems) in /live/ (see find_livefs() in 9990-misc-helpers.sh.

#22 Updated by intrigeri 4 months ago

I can't find a way to make grub tell us the boot device.

This might help:

probe --fs-uuid ($root)

Documentation: https://www.gnu.org/software/grub/manual/grub/grub.html#probe

But that only works if $root is already set to the partition where GRUB was loaded from, and usually one sets $root in grub.cfg by searching for the drive that has the already-known UUID where GRUB was installed. So perhaps there's a chicken'n'egg problem here and this suggestion is not helpful. In our 64-bit UEFI + GRUB test images, are $prefix and $root set automatically by GRUB on startup?

If we don't find an option for that, the only alternative I see is to do the same thing live-boot does to choose the boot device, which is trying to mount all removable devices and choose the first one that contains a squashfs (or other filesystems) in /live/ (see find_livefs() in 9990-misc-helpers.sh.

It seems that in the end, we decided to repartition only on first boot. Then, what about this: at build time we know what the initial UUID for the FAT filesystem is going to be, so we can hard-code this somewhere in the FAT partition or in the initrd, and then use that in the partitioning script? This can cause trouble if 2 never-booted-yet Tails devices are plugged in, but I believe our current implementation already has this problem.

#23 Updated by segfault 4 months ago

intrigeri wrote:

I can't find a way to make grub tell us the boot device.

This might help:

[...]

Documentation: https://www.gnu.org/software/grub/manual/grub/grub.html#probe

Thanks, I also found that yesterday :)

But that only works if $root is already set to the partition where GRUB was loaded from, and usually one sets $root in grub.cfg by searching for the drive that has the already-known UUID where GRUB was installed. So perhaps there's a chicken'n'egg problem here and this suggestion is not helpful. In our 64-bit UEFI + GRUB test images, are $prefix and $root set automatically by GRUB on startup?

Yes, $root is set up automatically by GRUB.

#24 Updated by segfault 4 months ago

  • Status changed from Confirmed to In Progress

#25 Updated by segfault 4 months ago

  • Description updated (diff)

I pushed a commit which uses GRUB's probe command to set FSUUID on the kernel command-line. But I had to install grub from sid for that, the grub from buster doesn't seem to support the probe command (which is strange because the command is older than the 2.02 release that Buster's grub is based on, and I see grub-core/commands/probe.c in the Debian packaging repo on tag debian/2.02+dfsg1-20).

#26 Updated by intrigeri 4 months ago

the grub from buster doesn't seem to support the probe command (which is strange because the command is older than the 2.02 release that Buster's grub is based on, and I see grub-core/commands/probe.c in the Debian packaging repo on tag debian/2.02+dfsg1-20).

I think this can be explained by:

grub2 (2.04-3) unstable; urgency=medium

[…]
 * Add probe module to signed UEFI images (closes: #936082).

:)

#27 Updated by intrigeri 4 months 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.

#28 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#29 Updated by intrigeri about 1 month ago

  • Feature Branch changed from feature/6560-secure-boot to feature/6560-secure-boot+force-all-tests

#30 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#31 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#32 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#33 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#34 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#35 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#36 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#37 Updated by intrigeri about 1 month ago

  • Description updated (diff)

(Drafted manual testing plan.)

#38 Updated by intrigeri about 1 month ago

  • Description updated (diff)

(Add a few manual tests.)

#39 Updated by intrigeri about 1 month ago

  • Description updated (diff)

(Describe test protocol more precisely, report some results.)

#40 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#41 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#42 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#43 Updated by intrigeri about 1 month ago

  • Description updated (diff)

(Report success for all non-Etcher initial install scenarios.)

#44 Updated by intrigeri about 1 month ago

  • Description updated (diff)

(Clarify & fix how upgrade tests are done.)

#45 Updated by intrigeri about 1 month ago

  • Description updated (diff)

(Reporting success for all non-Etcher tests.)

#46 Updated by intrigeri about 1 month ago

  • Description updated (diff)

#47 Updated by intrigeri 17 days ago

#48 Updated by intrigeri 17 days ago

  • Parent task set to #6560

#49 Updated by intrigeri 13 days ago

  • Status changed from In Progress to Needs Validation
  • Assignee set to sajolida

@sajolida, could you please do the Etcher tests listed as "TODO" in the ticket description? I see no reason why there could be a regression (we're copying a disk image bit-by-bit after all!) but still, better safe than sorry.

If it works fine, please close this ticket as resolved :)

#50 Updated by intrigeri 11 days ago

  • Status changed from Needs Validation to Resolved

#51 Updated by sajolida 11 days ago

  • Assignee deleted (sajolida)

Also available in: Atom PDF