Project

General

Profile

Feature #15806

Use GRUB for USB boot on EFI 64-bit

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

Status:
In Progress
Priority:
High
Assignee:
-
Category:
-
Target version:
Start date:
08/18/2018
Due date:
% Done:

0%

Feature Branch:
feature/6560-secure-boot
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'
  • Ensure this does not break stuff on legacy BIOS boot, 32-bit EFI, nor DVD boot
  • Update our test suite accordingly: it currently expects the syslinux UI
  • Update our documentation about editing the kernel command line accordingly
  • Update our design doc accordingly

Team: FT


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
Related to Tails - Bug #16229: Boot Loader Menu documentation does not support 32-bit UEFI Confirmed 12/17/2018
Blocks Tails - Feature #6560: UEFI Secure boot In Progress 01/02/2014
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 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 99fd55d4 (diff)
Added by segfault 15 days ago

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

Also adds a troubleshoot entry.

Revision 783874cd (diff)
Added by segfault 14 days 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.

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 about 1 year ago

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

#8 Updated by intrigeri 8 months ago

#9 Updated by intrigeri 8 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 8 months ago

  • Description updated (diff)

#11 Updated by intrigeri 8 months ago

  • Description updated (diff)

#12 Updated by intrigeri 8 months ago

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

#13 Updated by intrigeri 8 months ago

  • Status changed from Confirmed to In Progress

#14 Updated by intrigeri 8 months ago

  • Status changed from In Progress to Confirmed

#15 Updated by segfault 4 months ago

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

#16 Updated by intrigeri 3 months ago

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

#17 Updated by intrigeri 3 months ago

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

#18 Updated by intrigeri 3 months ago

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

#19 Updated by intrigeri 3 months ago

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

#20 Updated by intrigeri 2 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 15 days 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 14 days 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 14 days 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 14 days ago

  • Status changed from Confirmed to In Progress

#25 Updated by segfault 14 days 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 14 days 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 7 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