Bug #17561

Release process: SquashFS file order vs. Secure Boot

Added by CyrilBrulebois 2020-03-26 21:39:35 . Updated 2020-05-06 04:28:58 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Tails_4.7
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Preparing 4.5~rc1, I’m now wondering whether it is important to have Secure Boot explicitly enabled or disabled when profiling the boot sequence to proceed with the SquashFS file order update.

I haven’t looked at what happened exactly in a boot sequence with Secure Boot enabled… but we might be missing some signatures if the RM doesn’t use a Secure Boot enabled system? Checking the contents of a current linux-image package, it seems like the signatures are embedded directly into the vmlinuz kernel binary and individual .ko modules, rather than being shipped alongside them. But there might be some other things I haven’t thought of…

Definitely not a blocker for 4.5~rc1, but I suppose it would be slightly safer to have an answer before the final 4.5 release.

Poking intrigeri and segfault accordingly.

Subtasks

History

#1 Updated by CyrilBrulebois 2020-03-26 21:42:26

And possibly more importantly: what about Legacy BIOS vs. UEFI?

(I’m assuming we might be more interested in the UEFI boots, if there were any differences and if we needed to pick one.)

#2 Updated by intrigeri 2020-03-27 10:44:02

Hi,

thanks for caring!

I really doubt these would impact boot-time file access in the SquashFS in a way that careful ordering would make a significant performance difference:

  • Legacy BIOS vs. UEFI: should not matter once we’re at the “reading from SquashFS” stage, i.e. the root filesystem has been mounted.
  • “Secure Boot or not”: I’m not aware of any detached signatures either.

Even if there were differences here, for me it’s in the same category as other divergences, such as the hardware the RM is booting the almost final image from (which determines which kernel modules are loaded, which udev rules are triggered, that can call out to external programs). We’ve been ignoring such divergences so far and I’m not aware of any problem this has caused in practice.

#3 Updated by CyrilBrulebois 2020-04-07 17:05:25

  • Target version changed from Tails_4.5 to Tails_4.6

#4 Updated by CyrilBrulebois 2020-05-06 04:28:58

  • Target version changed from Tails_4.6 to Tails_4.7