Re: Can't unlock LUKS2 encrypted boot partition with GRUB

[Mike Benson]

I am now fairly sure this is a bug. Looking at luks2.c, it looks like the
code is assuming there is a one-to-one mapping between keyslots, digests,
and segments. In the trivial case (keyslot=0, digest=0, segment=0) this is
true, but the code can't handle my setup (keyslot=1, digest=0, segment=0),
even though cryptsetup can.

On Tue, 7 Jul 2020 at 08:10, Mike Benson <mike@kambe.com.au> wrote:

> I am playing around with full disk encryption, but Grub is not being
> cooperative.
>
> I am using a build of Grub cloned from the Git repository, so luks2
> support is available. I have run grub-mkconfig and grub-install, preloading
> part_gpt, luks2 and cryptodisk modules
>
> The boot partition is locked with two keys at the moment. The second is a
> temporary, memorable (but low entropy) passphrase for testing.
>
> If I boot from the live usb, I can do:
> *Code:*
> cryptsetup luksOpen /dev/nvme0n1p2 BOOT
>
> and that works fine with the second key.
>
> When I boot the target, I get a "no such device" error and get dropped
> into a rescue shell. I'll deal with that later.
>
> I type:
> *Code:*
> set debug=all
> cryptomount (hd0,gpt2)
> ...
> Enter passphrase for hd0,gpt2 (<UUID follows>): <Types passphrase>
> disk/luks2.c:598: Trying keyslot 0
> disk/luks2.c:613: Decryption with keyslot 0 failed
> ...
> error: Could not parse digest 1.
>
>
> If I do a luksDump, I can confirm there is no digest 1 (although there is
> a digest 0, referenced by both keyslots). I don't know if this is a bug
> with searching the keyslots, or a problem with the LUKS header (though
> surely cryptsetup would have problems if that were the case).
>
> Any grub masters available to offer suggestions?
>