Feature #6560

UEFI Secure boot

Added by intrigeri 2014-01-02 04:01:26 . Updated 2020-04-06 21:55:10 .

Status:
Resolved
Priority:
High
Assignee:
intrigeri
Category:
Hardware support
Target version:
Tails_4.5
Start date:
2018-12-17
Due date:
% Done:

100%

Feature Branch:
feature/6560-secure-boot+force-all-tests, https://salsa.debian.org/tails-team/tails/-/merge_requests/44/
Type of work:
Code
Blueprint:

https://tails.boum.org/blueprint/UEFI_Secure_boot/

Starter:
0
Affected tool:
Deliverable for:

Description

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

Team: FT

Subtasks

Feature #15806: Use GRUB for USB boot on EFI 64-bit Resolved

100
Bug #17352: Release alpha with Secure Boot, GRUB, and overlayfs Resolved

100
Feature #17452: Figure out what to do with VirtualBox dkms modules vs. Secure Boot Resolved

100
Feature #17459: Triage user feedback wrt. Secure Boot alpha Resolved

100
Feature #17492: Update documentation wrt. using GRUB + Secure Boot for USB boot on EFI 64-bit Resolved

100
Feature #17538: Make it easy for users to identity whether they get GRUB or SYSLINUX Resolved

100

Related issues

Related to Tails - Feature #11679: Rethink the installation process and upgrade process Resolved 2016-08-20
Related to Tails - Bug #15016: Explain better how to disable Secure Boot Rejected 2017-12-05
Blocked by Tails - Feature #5739: Support UEFI boot Resolved 2013-10-03
Blocked by Tails - Feature #15292: Distribute a USB image Resolved 2016-04-14 2019-01-29
Blocked by Tails - Feature #8415: Migrate from aufs to overlayfs Resolved 2014-12-18
Blocked by Tails - Feature #15944: Port Tails to Buster Resolved 2018-09-12
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed
Blocks Tails - Feature #17495: Run most of our test suite with Secure Boot enabled Confirmed

History

#1 Updated by intrigeri 2014-01-02 04:07:18

  • Category set to Hardware support

#2 Updated by intrigeri 2014-01-02 04:10:58

  • Priority changed from Normal to Low

#3 Updated by BitingBird 2014-05-27 10:59:35

  • 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 2014-05-27 11:11:01

  • 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 2017-07-16 18:58:35

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 2018-02-03 16:24:59

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

#7 Updated by intrigeri 2018-02-06 16:04:55

#8 Updated by intrigeri 2018-08-17 06:14:16

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

#9 Updated by intrigeri 2018-08-17 06:24:40

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 Feature #15292 is done, if it’s cheaper the ISO can keep using isolinux and not support Secure Boot.

#10 Updated by intrigeri 2018-08-18 14:04:58

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

#11 Updated by intrigeri 2018-09-14 11:37:55

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

#12 Updated by sajolida 2018-11-04 04:23:30

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 2018-11-05 09:37:34

> 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 2018-11-06 01:09:51

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 2018-12-22 18:20:40

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 2018-12-24 09:18:27

> 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 2019-01-12 16:34:01

#18 Updated by intrigeri 2019-01-12 16:36:01

> Blocked by Feature 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 Feature #8415, which is itself blocked by Feature #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.

#19 Updated by sajolida 2019-03-14 17:02:58

  • related to #15885 added

#20 Updated by intrigeri 2019-04-02 15:26:22

#21 Updated by intrigeri 2019-04-05 16:09:51

#22 Updated by intrigeri 2019-04-11 13:58:31

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|69157449b1d90b6f3fd170e4485b83c7134aa8f4.

#23 Updated by intrigeri 2019-04-11 13:59:02

  • 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 2019-09-13 07:14:41

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

#25 Updated by segfault 2019-11-27 17:25:49

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|3da2ff54fc73abc8da1da170ba941406ae5cd08e.

#26 Updated by intrigeri 2019-12-01 11:24:36

  • 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.

#27 Updated by intrigeri 2020-02-21 15:24:54

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

#28 Updated by intrigeri 2020-02-22 07:22:56

  • related to Feature #17492: Update documentation wrt. using GRUB + Secure Boot for USB boot on EFI 64-bit added

#29 Updated by intrigeri 2020-02-23 07:08:34

  • blocks Feature #17495: Run most of our test suite with Secure Boot enabled added

#30 Updated by intrigeri 2020-03-15 15:43:46

  • blocks deleted (Feature #15806: Use GRUB for USB boot on EFI 64-bit)

#31 Updated by anonym 2020-03-18 14:51:34

  • Status changed from In Progress to Needs Validation
  • Assignee set to anonym
  • Feature Branch changed from feature/6560-secure-boot+force-all-tests to feature/6560-secure-boot+force-all-tests, https://salsa.debian.org/tails-team/tails/-/merge_requests/44/

I’ll review this on GitLab, looking at the diff, not the commits (which stretch back to 2015! Eeek!).

#32 Updated by anonym 2020-03-19 17:31:28

  • Assignee changed from anonym to intrigeri

Woohoo! Great work, you two! I’m almost a bit unhappy with how little I had to remark about. :D Non of them are really blockers, IMHO.

So, I am in particular done with all the code, so I deem this merge-worthy, but I would like to give another pass to the changes of docs and automated tests (honestly, that linting commit made things harder for me, and I am very glad it was only applied to usb.rb), which I plan to do tomorrow (2020-03-20) morning. But I don’t think you should block on this. So, at least from my PoV, feel free to go ahead and merge whenever you want.

#33 Updated by intrigeri 2020-03-20 08:53:13

  • Status changed from Needs Validation to In Progress

Hi @anonym,

> Woohoo! Great work, you two! I’m almost a bit unhappy with how little I had to remark about. :D Non of them are really blockers, IMHO.
> So, I am in particular done with all the code, so I deem this merge-worthy,

Sweet! Does this mean you agree Bug #15146 is not a blocker, or did you miss it so far?

I’ll look at your code review this morning and I should manage to push the corresponding follow-up commits today. Then I’ll reassign to you for another review pass (without waiting for CI results).

> honestly, that linting commit made things harder for me, and I am very glad it was only applied to usb.rb

Yeah, in retrospect I should have dropped that commit once I realized that the amount of changes needed to get a significant benefit (having the linting tool not disabling itself in my editor because of “too many problems, giving up!”) was much bigger than I expected. Sorry for the burden!

And to put this into perspective, IMO this relates to the problem introduced with “We have a hard time balancing these aspects” in summit.git:WIP/Healing_our_community.mdwn: it was easier and more pleasurable for me to do this work while I was there, but it caused trouble for you.

Off-topic: I’d really like us to have coding standards, ideally not too far from established Ruby best practices. So I’ll try to come back to this and do a PoC mass linting in a dedicated branch. Then we can decide how much we value personal preferences over established best practices, which may result in disabling some of the linting rules in a config file in Git, so everyone’s brain/editor/IDE/linter can be aware of our coding standards.

> So, at least from my PoV, feel free to go ahead and merge whenever you want.

FTR, before merging I’ll block on:

  • One of anonym & segfault commenting on Bug #15146
  • kibi’s “what can possibly go wrong” intput

#34 Updated by intrigeri 2020-03-20 09:18:07

  • Status changed from In Progress to Needs Validation
  • Assignee changed from intrigeri to anonym

> I’ll look at your code review this morning and I should manage to push the corresponding follow-up commits today. Then I’ll reassign to you for another review pass (without waiting for CI results).

Done! (I’ll monitor CI results.)

#35 Updated by anonym 2020-03-20 09:36:19

intrigeri wrote:
> Hi anonym,
>
> > Woohoo! Great work, you two! I’m almost a bit unhappy with how little I had to remark about. :D Non of them are really blockers, IMHO.
> > So, I am in particular done with all the code, so I deem this merge-worthy,
>
> Sweet! Does this mean you agree Bug #15146 is not a blocker, or did you miss it so far?

Gah, I had forgotten to click the “Submit” button for the post I wrote yesterday. But yes, Bug #15146 is not a blocker, IMHO.

> I’ll look at your code review this morning and I should manage to push the corresponding follow-up commits today. Then I’ll reassign to you for another review pass (without waiting for CI results).

Ack! I’ll also do another pass on the docs and tests, as I said yesterday.

> > honestly, that linting commit made things harder for me, and I am very glad it was only applied to usb.rb
>
> Yeah, in retrospect I should have dropped that commit once I realized that the amount of changes needed to get a significant benefit (having the linting tool not disabling itself in my editor because of “too many problems, giving up!”) was much bigger than I expected. Sorry for the burden!
>
> And to put this into perspective, IMO this relates to the problem introduced with “We have a hard time balancing these aspects” in summit.git:WIP/Healing_our_community.mdwn: it was easier and more pleasurable for me to do this work while I was there, but it caused trouble for you.

Fully understood! There are (and were) absolutely no hard feelings! :)

> Off-topic: I’d really like us to have coding standards, ideally not too far from established Ruby best practices. So I’ll try to come back to this and do a PoC mass linting in a dedicated branch. Then we can decide how much we value personal preferences over established best practices, which may result in disabling some of the linting rules in a config file in Git, so everyone’s brain/editor/IDE/linter can be aware of our coding standards.

Sounds great, fully agreed!

#36 Updated by anonym 2020-03-20 09:50:13

anonym wrote:
> intrigeri wrote:
> > I’ll look at your code review this morning and I should manage to push the corresponding follow-up commits today. Then I’ll reassign to you for another review pass (without waiting for CI results).

Your fixes look good!

> I’ll also do another pass on the docs and tests, as I said yesterday.

I’ll proceed with this now.

#37 Updated by anonym 2020-03-20 10:13:47

  • Assignee changed from anonym to intrigeri

anonym wrote:
> anonym wrote:
> > I’ll also do another pass on the docs and tests, as I said yesterday.
>
> I’ll proceed with this now.

Done! Nothing new to add. :)

#38 Updated by intrigeri 2020-03-21 18:28:48

  • Status changed from Needs Validation to Resolved

Applied in changeset commit:tails|7ca99d6f0e1670dc0c5daedf13a449528d5a7783.