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

[Patrick Steinhardt]

On Fri, Aug 28, 2020 at 11:37:24AM -0400, Eli Schwartz wrote:
> On 8/28/20 11:28 AM, HardenedArray via Grub-devel 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.
> > 
> > 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?
> > 
> > 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>`.
> > 
> > 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.`
> > 
> > Very frustrating indeed!
> > 
> > Does anyone know why grub is failing this way, and does a workaround
> > exist?
> > 
> > Thank you for your time...suggestions welcome.
> 
> If I remember correctly, you mentioned on IRC that you could
> successfully use grub-git to cryptomount a luks1 /boot/grub directory,
> then use the grub modules there to further cryptomount a luks2 partition.
> 
> The problem sounded like an issue actually getting grub-install to
> generate a grubx64.efi with proper, usable luks2 support.
> 
> Am I right?

If that's the case, then this is entirely expected right now.
grub-install doesn't yet include the required modules automatically for
LUKS2 support. There is ongoing work to enable this, first by
recognizing LUKS2 devices at all [1,2]. But we're not there yet, and
it's unlikely to happen for release 2.06.

Until then, you'll have to manually add required GRUB modules for LUKS2,
PBKDF2 and the gcry modules required for your configured cipher/hash
combination.

Patrick

[1]: https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00235.html
[2]: https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00050.html

signature.asc
Description: PGP signature