@mkukri Thanks for the clarification on support policy. However, I think the “intended way” you describe (plaintext /boot, signed boot assets, initrd unlocks root) leaves a significant integrity gap for the travel / evil‑maid threat model:
1. With Secure Boot, you get signature enforcement for shim/GRUB and (typically) the kernel image, but the initrd is not validated as part of that chain. 2. If /boot is readable in clear, an attacker with temporary physical access can modify initrd (or its contents) to capture the LUKS passphrase at boot and exfiltrate it later, while still booting a signed kernel. That defeats the main goal of Secure Boot + FDE for people who travel and worry about pre‑boot tampering. 3. So “plaintext /boot + initrd unlock” is not just a different preference—it materially changes the security guarantees vs “GRUB unlocks encrypted /boot”, because the latter keeps the boot-critical assets (including initrd) inside the encrypted boundary until the user authenticates. Given that, I’d ask for one of the following: 1. If Ubuntu’s position is “we do not support encrypted /boot under Secure Boot”, please document the above integrity limitation explicitly (i.e., Secure Boot does not protect initrd integrity in this configuration). 2. Alternatively, if the recommended secure design is “signed kernel + signed initrd”, can you point to the officially supported mechanism to achieve that on Ubuntu (e.g., using a unified kernel image approach where initrd is inside the signed EFI payload), since the current “plaintext /boot + initrd unlock” approach does not provide the same tamper resistance? 3. Or, if that is not planned, please reconsider the blanket refusal to ship/sign the required GRUB modules for this use case—because for users with this threat model, the current recommendation effectively forces a weaker pre‑boot integrity story. To be clear: I’m not asking for an exotic setup; I’m asking for a configuration that preserves the Secure Boot threat model (pre‑boot tampering resistance) when using full-disk encryption. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2141233 Title: 26.04: outdated signed GRUB (Secure Boot) cannot unlock LUKS2 /boot with Argon2 (argon2i/argon2id) KDF – needs update + signed artifacts parity To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/2141233/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
