Release process: SquashFS file order vs. Secure Boot
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.
intrigeri and segfault accordingly.
#2 Updated by intrigeri 2020-03-27 10:44:02
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.