Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results

[Glenn Washburn]

On Fri, 28 Aug 2020 15:28:41 +0000
HardenedArray via Grub-devel <grub-devel@gnu.org> wrote:

> I run Arch Linux as an encrypted /, /boot and swap system. That
> encrypted /boot is nothing more than a folder under /, however two
> Keyslots are required to boot.
> 
> If I understand the boot process correctly, LUKS Keyslot 1 is used by
> grub to unlock /boot, then control is handed off to the kernel which
> uses Keyslot 0 to unlock /. My passphrase, entered once, unlocks both.

This is confusing.  Do you have a two LUKS devices, one for / and one
for /boot?  If so, you only need to access LUKS Keyslot 0 on either
device.

> Grub can easily unlock /boot, assuming / is originally encrypted as a
> `type= luks1` partition. It seems, however, it is not possible for
> grub to unlock this same /boot if / is converted to `--type= luks2`.
> 
> Is my assumption correct, and if so, what is preventing grub from
> this `type= luks2` /boot unlocking?

Please post the output of `cryptsetup luksDump --debug-json <luks
device>' (for both /boot and / if using two LUKS devices).

> I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR).
> This package was last updated on 7 Feb 2020. See:
> https://aur.archlinux.org/packages/grub-git/
> 
> I originally encrypted the partition with: `cryptsetup -c
> aes-xts-plain64 -h sha512 -s 512 --use-random --type luks1 luksFormat
> /dev/sdXZ`
> 
> Then I set up two LVs: swap (512M) and / (remaining partition space).
> That swap LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2
> runs BTRFS, if that matters. Grub boots that system without issue.
>
> The process I used to test LUKS2 encrypted /boot support:
> 
> 1. UEFI boot from any reasonably recent arch iso, and run:
> `cryptsetup convert --type luks2 /dev/sdXZ`. That command will
> succeed, and luksDump will show PBKDF: pbkdf2 for both Keyslot 0 and
> 1.
> 
> 2. Run cryptsetup open /dev/sdXY <something>
> 
> 3. Mount everything and arch-chroot into /
> 
> 4. Run `mkinitcpio -P linux`
> 
> 5. Run `grub-install --target=x86_64-efi --efi-directory=/efi
> --modules="luks2 part_gpt cryptodisk" --bootloader-id=<some-id>`.

Is /efi on the encrypted /boot partition?  If so how are you going to
get the BIOS to boot it?

> Note: If `--modules="luks2 part_gpt cryptodisk" ` is not appended to
> grub-install, then the `ls` results in step 9 (below) only lists
> (proc) and (hd0) - and/or cryptodisk: command not found.
> 
> 6. Run grub-mkconfig -o /boot/grub/grub.cfg
> 
> 7. Exit, umount and reboot.
> 
> 8. Immediately following power on: you are greeted by the dreaded:
> error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue
> mode. That lengthy UUID is exact UUID of my `dm-2` which is my
> encrypted / LV.
> 
> 9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0)
> and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where
> my encrypted / resides.
> 
> 10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then
> requires my passphrase. After correct passphrase entry, and hitting
> Enter only returns:
> 
> `error: Could not parse digest 1.`
> 
> Incredibly, if you repeat step 10 and intentionally enter an
> incorrect passphrase, you get the same:
> 
> `error: Could not parse digest 1.`
> 
> In fact, if you enter NO passphrase and hit Enter, you also get:
> 
> `error: Could not parse digest 1.`

It looks like you're hitting the bug in master which is triggered by
attempting to cryptomount a LUKS device using a keyslot that is not the
first one.  Could you post the output of `cryptsetup luksDump
--debug-json <luks device>'?

That bug is fixed by the patch on this mailing list with title "[PATCH
v2 3/9] luks2: Fix use of incorrect index and some error  messages".

> Very frustrating indeed!
> 
> Does anyone know why grub is failing this way, and does a workaround
> exist?
> 
> Thank you for your time...suggestions welcome.

Glenn