On Wed, 8 Jul 2020 11:02:57 +1000 Mike Benson <[email protected]> wrote:
> 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. Yes, there are bugs in that code. I just submitted some patches, that I believe will fix this issue in the grub-devel list. I'm curious to hear if they do. > On Tue, 7 Jul 2020 at 08:10, Mike Benson <[email protected]> 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? > >
