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

[HardenedArray]

Hi Eli,

Unless I missed what I said in this very long, convoluted LUKS2 IRC history, I 
do not recall telling you that I could cryptomount from a --type luks1 
partition, simply because I had never had a reason to do so.

Again, grub boots my luks1 encrypted /boot system without issue, meaning I 
enter my passphrase at the grub (correct /dev/sda7 UUID) prompt (and NOT the 
`grub rescue>`) prompt and then boot continues until I reach KDE's SDDM login.

What I think I told you is:  once I'm logged into KDE on my luks1 encrypted 
/boot system, I can easily mount another luks2 encrypted / on another 
partition, be that Fedora or some other OS.  No cryptomount command or `grub 
rescue> prompt involved.  Only entering the correct LUKS passphrase is required.

Hope that helps...



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, August 28, 2020 3:37 PM, Eli Schwartz <eschwartz@archlinux.org> 
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
> >
> > 2.
> > 3.  Run cryptsetup open /dev/sdXY <something>
> >
> > 4.  Mount everything and arch-chroot into /
> >
> > 5.  Run `mkinitcpio -P linux`
> >
> > 6.  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?
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Eli Schwartz
> Arch Linux Bug Wrangler and Trusted User
>
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel