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

[HardenedArray]

Patrick,

I truly appreciate your deep knowledge of grub, and I am happy to report I 
think we have a working LUKS2 encrypted /boot solution based on your input!

As I told everyone here, previously:

I originally encrypted my / partition with: `cryptsetup -c aes-xts-plain64 -h 
sha512 -s 512 --use-random --type luks1 luksFormat /dev/sdXZ`

Of course, I 'converted' /dev/sdXZ to `--type luks2` prior to any further 
testing.

Therefore, based on Patrick's input:

> Sorry, I probably wasn't clear enough on the gcry part. "gcry" is not a
> single module, but instead it is a set of modules which implement the
> cryptographic primitives required for LUKS2. So e.g. if you use
> "aes-xts-plain64" with a PBKDF2-derived key using SHA256, you'd at
> least need the "gcry_rijndael", "pbkdf2" and "gcry_sha256" modules. But
> this really depends on your specific setup.

I ran:

grub-install --target=x86_64-efi --efi-directory=/efi --modules="luks2 part_gpt 
cryptodisk gcry_rijndael pbkdf2 gcry_sha512" --bootloader-id=<some-id>`.

That installation command completed without error.

Then, obviously, grub-mkconfig, exit, umount, and reboot.

As before/always, following reboot, I am treated to:

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.

However this time:  cryptomount (hd0,gpt7) results in significant difference:

Following CORRECT passphrase entry:  You will see:  Slot 0 opened, and then you 
are immediately returned to the `grub rescue>` prompt.

If you now type 'ls', unlike before, you will now see something similar to:  
(proc) (hd0)
and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where my 
encrypted / resides.  ADDITIONALLY, you should now also see your LVs similar 
to:   (/lvm/ArchSDD-root) and (lvm/ArchSSD-swap) depending upon your local 
naming convention decisions.

>From this still sad NON-BOOTED state of affairs, it merely took me hours of 
>research to undig myself from this self-inflicted grave!

from `grub rescue>` type:  'insmod normal'

from `grub rescue>` type:  'normal'

That should launch your typical/welcome Arch Linux and Advanced options for 
Arch Linux screen as controlled by /etc/default/grub and by X.

My launcher (with multiple kernels, and various OSes) works...hope yours does 
also!

Thanks again, Patrick!



‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

> Hi,
>
> On Sat, Aug 29, 2020 at 09:00:41AM +0000, HardenedArray wrote:
>
> > Hi Patrick,
> > Yes, I am on the mailing list.
>
> Okay. I'm re-adding the ML to the receipients.
>
> > I tried appending all the modules you mentioned below to `--modules=`
> > However, when I ran `grub-install --target=x86_64-efi --efi-directory=/efi 
> > --modules="luks2 part_gpt cryptodisk pbkdf2 gcry" --bootloader-id=<some-id>
> > I get:
> > grub-install: error: '/usr/lib/grub/x86_64-efi/gcry.mod' : No such file or 
> > directory.
>
> Sorry, I probably wasn't clear enough on the gcry part. "gcry" is not a
> single module, but instead it is a set of modules which implement the
> cryptographic primitives required for LUKS2. So e.g. if you use
> "aes-xts-plain64" with a PBKDF2-derived key using SHA256, you'd at
> least need the "gcry_rijndael", "pbkdf2" and "gcry_sha256" modules. But
> this really depends on your specific setup.
>
> Patrick
>
> > Therefore, I re-ran the above grub-install removing only the 'gcry` module.
> > That command completes without error. The complete (lengthy) grub-install 
> > -v output is at: http://ix.io/2vyc
> > However, after grub-mkconfig, exiting, umounting and rebooting, I am right 
> > back to the identical output and passphrase entry issues I detailed in my 
> > Steps 9 and 10 below.
> > Any ideas about 'gcry' or another testing approach?
> > Cheers
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, August 28, 2020 4:52 PM, Patrick Steinhardt ps@pks.im wrote:
> >
> > > Manually Cc'ing you as I don't know if you're registered on the mailing
> > > list and saw just now that you weren't Cc'd on my initial reply.
> > > ----- Forwarded message from Patrick Steinhardt ps@pks.im -----
> > >
> > > > From: Patrick Steinhardt ps@pks.im
> > > > To: The development of GNU GRUB grub-devel@gnu.org
> > > > Date: Fri, 28 Aug 2020 18:51:21 +0200
> > > > Subject: Re: Can grub-git be used to decrypt a LUKS2 encrypted 
> > > > partition? Testing Results
> > > > 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
> > > > > >
> > > > > > 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?
> > > >
> > > > 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
> > >
> > > ----- End forwarded message -----
>
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel