[Bug 2141233] Re: 26.04: outdated signed GRUB (Secure Boot) cannot unlock LUKS2 /boot with Argon2 (argon2i/argon2id) KDF – needs update + signed artifacts parity

Sun Feb 8 23:08:46 UTC 2026

@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
Foundations Bugs, which is subscribed to grub2-signed in 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

Status in grub2-signed package in Ubuntu:
  Invalid

Bug description:
  A common setup is to use a separate encrypted /boot partition that
  must be unlocked by GRUB (cryptodisk) in order to load the kernel and
  initramfs. On Secure Boot systems, the boot path uses Ubuntu’s signed
  GRUB EFI binaries, so this capability must be present in the signed
  artifacts shipped via grub2-signed, not only in the unsigned build.

  With the current Ubuntu 26.04 GRUB packaging snapshot lineage, GRUB
  cannot unlock LUKS2 keyslots using Argon2 KDF (argon2i / argon2id). In
  the current snapshot, the LUKS2 decrypt path still hard-fails with
  “Argon2 not supported”, which blocks Secure Boot users from booting
  systems with an encrypted /boot that uses Argon2.

  Argon2 (especially Argon2id) is considered a stronger, more modern
  password-based key derivation approach than PBKDF2 for protecting
  encrypted volumes against offline cracking, because it is memory-hard
  rather than mostly CPU-bound. This matters for encrypted /boot, where
  a stolen disk enables unlimited offline guessing, and being forced to
  PBKDF2 due to bootloader limitations is a real security downgrade.

  Steps to reproduce:

  1.Enable Secure Boot in firmware/UEFI.
  2. Create a separate LUKS2 partition for /boot with keyslot KDF = argon2id (or argon2i).
  3. Install Ubuntu 26.04 (daily/devel) using the default Secure Boot path (signed GRUB).
  4. Boot and enter the LUKS passphrase at the GRUB prompt.

  Actual result:
  Signed GRUB fails to unlock /boot when the keyslot uses Argon2 KDF (the decrypt path hard-fails with “Argon2 not supported”).

  Expected result:
  Signed GRUB successfully derives the key using Argon2 and unlocks the LUKS2 /boot partition, then continues boot.

  Additional info / evidence:

  1. Ubuntu 26.04 devel currently uses GRUB snapshot 2.14~git20250718.0e36779 lineage; the unsigned source package page is:
      https://launchpad.net/ubuntu/+source/grub2-unsigned

      (In grub-core/disk/luks2.c, luks2_decrypt_key() returns “Argon2 not supported” for Argon2 KDF type in this snapshot.)

  2. Signed GRUB is delivered via the grub2-signed source package:
      https://launchpad.net/ubuntu/+source/grub2-signed

  3. There is an upstream grub-devel patch series adding Argon2 KDF support for LUKS2 (e.g. “disk/luks2: Add Argon2 support”).
      Upstream thread: https://www.mail-archive.com/grub-devel@gnu.org/msg41723.html

  4. Link to the related grub2-unsigned bug for the core implementation
  update; this grub2-signed bug is to ensure Secure Boot parity:
  https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/2141232

  Request:
  Please update Ubuntu 26.04 signed GRUB (grub2-signed) to a version (upstream 2.14 release tarball or newer snapshot) that includes LUKS2 Argon2 KDF unlock support for cryptodisk, and ensure the signed EFI images shipped for Secure Boot include this functionality.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/2141233/+subscriptions