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

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 6822 bytes --]

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 -----

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

On Sat, Aug 29, 2020 at 04:27:11PM +0000, HardenedArray via Grub-devel wrote:
> 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!

Glad it worked!

[snip]
> 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.

This is usually done automatically by GRUB when starting. But as it'll
not know to first decrypt the volume, it fails executing both of those
commands just to show you the rescue prompt afterwards. So they are left
to you now after manually decrypting. I could've added a note up-front
to spare you the hours-long research, but it got so natural to me that I
completely forgot.

You should be able to manually create a bootable image with GRUB with
`grub-mkimage`. The upside of this is that you can add your own early
configuration to automatically decrypt and do the `normal` dance. I
didn't care enought to do that myself yet, though, so I can't provide a
working invocation of that.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1380 bytes --]

On 8/29/20 1:47 PM, Patrick Steinhardt wrote:
> This is usually done automatically by GRUB when starting. But as it'll
> not know to first decrypt the volume, it fails executing both of those
> commands just to show you the rescue prompt afterwards. So they are left
> to you now after manually decrypting. I could've added a note up-front
> to spare you the hours-long research, but it got so natural to me that I
> completely forgot.
> 
> You should be able to manually create a bootable image with GRUB with
> `grub-mkimage`. The upside of this is that you can add your own early
> configuration to automatically decrypt and do the `normal` dance. I
> didn't care enought to do that myself yet, though, so I can't provide a
> working invocation of that.

Is grub-install failing to add the relevant cryptomount invocation in
the embedded stub, due to not realizing luks2 can be decrypted like that?

I wonder if you could hack this to work by relying on autodetection with
grub-install --modules="..." to force luks2 modules to be included, but
with a luks1 "/" root partition. Then *after*, convert the partition
from luks1 to luks2. The grubx64.efi image should both support luks2 due
to manually added modules, AND automatically Do The Right Thing with the
generic cryptomount command.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1601 bytes --]

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

[HardenedArray]

Hi Patrick,

As a direct consequence of your valuable `--modules=` input, I have taken the time and attempted to carefully document my entire LUKS2 unlocking encrypted /boot process for the benefit of others, similarly situated.

My procedure and comments are posted at:  https://aur.archlinux.org/packages/grub-git/ under an intentionally Five Eyes 'unlinked' nick.  I know you understand.

Please take a moment to review my boot sequence comments within Step 11 and following Step 13, both of which are in concordance with my understanding of the GRUB encrypted /boot unlocking sequence.

If either statement needs modification, please let me know, as I do not want others to adopt an incorrect understanding of how both GRUB and the kernel go about unlocking Keyslot 1, then Keyslot 0.

Patrick, I've also noted Eli's further input, immediately below.

Given that you now know exactly how I've encrypted / and how I unlock my encrypted:  /boot, swap and /, if you can indeed 'hack' a suitable `grub-mkimage` command for me to test, I would be happy to test it.

However, please be sure to tell me whether you intend any such `grub-mkimage` directive to be a REPLACEMENT for `grub-mkconfig` or as a supplemental command.

All the best...Patrick

Cheers!


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, August 30, 2020 1:38 AM, Eli Schwartz <eschwartz@archlinux.org> wrote:

> On 8/29/20 1u47 PM, Patrick Steinhardt wrote:
>
> > This is usually done automatically by GRUB when starting. But as it'll
> > not know to first decrypt the volume, it fails executing both of those
> > commands just to show you the rescue prompt afterwards. So they are left
> > to you now after manually decrypting. I could've added a note up-front
> > to spare you the hours-long research, but it got so natural to me that I
> > completely forgot.
> > You should be able to manually create a bootable image with GRUB with
> > `grub-mkimage`. The upside of this is that you can add your own early
> > configuration to automatically decrypt and do the `normal` dance. I
> > didn't care enought to do that myself yet, though, so I can't provide a
> > working invocation of that.
>
> Is grub-install failing to add the relevant cryptomount invocation in
> the embedded stub, due to not realizing luks2 can be decrypted like that?
>
> I wonder if you could hack this to work by relying on autodetection with
> grub-install --modules="..." to force luks2 modules to be included, but
> with a luks1 "/" root partition. Then after, convert the partition
> from luks1 to luks2. The grubx64.efi image should both support luks2 due
> to manually added modules, AND automatically Do The Right Thing with the
> generic cryptomount command.
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

On Sat, Aug 29, 2020 at 09:38:53PM -0400, Eli Schwartz wrote:
> On 8/29/20 1:47 PM, Patrick Steinhardt wrote:
> > This is usually done automatically by GRUB when starting. But as it'll
> > not know to first decrypt the volume, it fails executing both of those
> > commands just to show you the rescue prompt afterwards. So they are left
> > to you now after manually decrypting. I could've added a note up-front
> > to spare you the hours-long research, but it got so natural to me that I
> > completely forgot.
> > 
> > You should be able to manually create a bootable image with GRUB with
> > `grub-mkimage`. The upside of this is that you can add your own early
> > configuration to automatically decrypt and do the `normal` dance. I
> > didn't care enought to do that myself yet, though, so I can't provide a
> > working invocation of that.
> 
> Is grub-install failing to add the relevant cryptomount invocation in
> the embedded stub, due to not realizing luks2 can be decrypted like that?

Yup. As I said in a previous mail, work to enable this is currently
still under review. We first landed LUKS2 decryption support on its own,
with tooling improvements and Argon2 support being the next step.

> I wonder if you could hack this to work by relying on autodetection with
> grub-install --modules="..." to force luks2 modules to be included, but
> with a luks1 "/" root partition. Then *after*, convert the partition
> from luks1 to luks2. The grubx64.efi image should both support luks2 due
> to manually added modules, AND automatically Do The Right Thing with the
> generic cryptomount command.

That does sound like quite a hack :) Even if it worked, it'd work only a
single time as you cannot re-convert the partition again. My take is
it'd probably be easier to just use grub-mkimage(1) instead with a
custom config , at least if there is a place where it's properly
documented.

In the end, all these are just stop-gap measures anyway until support
for auto-detection lands.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

On Sun, Aug 30, 2020 at 03:30:39PM +0000, HardenedArray via Grub-devel wrote:
> As a direct consequence of your valuable `--modules=` input, I have
> taken the time and attempted to carefully document my entire LUKS2
> unlocking encrypted /boot process for the benefit of others, similarly
> situated.

Great to have some documentation of the process, thanks!

> My procedure and comments are posted at:
> https://aur.archlinux.org/packages/grub-git/ under an intentionally
> Five Eyes 'unlinked' nick.  I know you understand.
> 
> Please take a moment to review my boot sequence comments within Step
> 11 and following Step 13, both of which are in concordance with my
> understanding of the GRUB encrypted /boot unlocking sequence.
> 
> If either statement needs modification, please let me know, as I do
> not want others to adopt an incorrect understanding of how both GRUB
> and the kernel go about unlocking Keyslot 1, then Keyslot 0.

I did a quick read and things look mostly fine. Partitions may obviously
change between installation, but I guess people can figure that out on
their own.

> Patrick, I've also noted Eli's further input, immediately below.
> 
> Given that you now know exactly how I've encrypted / and how I unlock
> my encrypted:  /boot, swap and /, if you can indeed 'hack' a suitable
> `grub-mkimage` command for me to test, I would be happy to test it.

I currently don't have any available, sorry. I never did the custom
config thing yet, even though it shouldn't be too hard. I hope to find
some time in the next few days to give it a test and will report back.

> However, please be sure to tell me whether you intend any such
> `grub-mkimage` directive to be a REPLACEMENT for `grub-mkconfig` or as
> a supplemental command.

It's not a replacement of `grub-mkconfig`, but is part of what
`grub-install` does. `grub-mkimage` will create the executable loaded by
your bootloader, which includes any pre-loaded modules as well as the
early boot config. `grub-mkconfig` will create the configuration that's
used after this early boot step and is loaded when you execute `normal`.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

On Sun, Aug 30, 2020 at 08:19:08PM +0200, Patrick Steinhardt wrote:
> On Sun, Aug 30, 2020 at 03:30:39PM +0000, HardenedArray via Grub-devel wrote:
> > Patrick, I've also noted Eli's further input, immediately below.
> > 
> > Given that you now know exactly how I've encrypted / and how I unlock
> > my encrypted:  /boot, swap and /, if you can indeed 'hack' a suitable
> > `grub-mkimage` command for me to test, I would be happy to test it.
> 
> I currently don't have any available, sorry. I never did the custom
> config thing yet, even though it shouldn't be too hard. I hope to find
> some time in the next few days to give it a test and will report back.

Well, you nerd-sniped me, so here you go:

```
#!/bin/bash

CONFIG=$(mktemp /tmp/grub-config.XXXXX)
cat >"$CONFIG" <<EOF
cryptomount -a

set prefix=(lvm/system-gentoo)/boot/grub
set root=lvm/system-gentoo

insmod normal
normal
EOF

grub-mkimage \
    -p '(lvm/system-gentoo)/boot/grub' \
    -O x86_64-efi \
    -c "$CONFIG" \
    -o /tmp/image \
    luks2 lvm gcry_rijndael gcry_sha256 gcry_sha512 part_gpt ext2 pbkdf2

rm "$CONFIG"
```

So what does this do? It creates a simple config that just directly
calls `cryptomount -a`, which would try to decrypt _all_ partitions. If
you have multiple encrypted disks, you can also use `cryptomount -u
$DISKUUID` instead. Afterwards, it sets up both prefix and root, which
in my case is the LVM volume "system/gentoo". Last, it does the
normal-dance.

We then use this configuration to build the EFI executable via
grub-mkimage. It again takes the prefix (it shouldn't be necessary here,
but it's a mandatory argument). It builds a 64 bit EFI executable with
our config and the set of modules we want it to include. These may again
need to be adjusted based on your system, e.g. if you use MSDOS instead
of GPT you'd need part_msdos instead of part_gpt. Same with filesystem
(ext2, which also handles ext3/ext4) and gcry modules.

Anyway, the resulting EFI executable is created at "/tmp/image". This is
the image you need to put into the typical "/boot/EFI/gentoo/grubx64.efi"
(paths obviously differ based on your system again).

Reboot and have fun. And thanks for finally fixing my own boot process
via your queries ;)

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[HardenedArray]

Hi Patrick,

Thank you for taking the time to have a look and if that LUKS2 unlocking process seems useful, please feel free to copypasta it, as needed.

Surely, I understand on the changing partitions part, which is why I attempted to keep `/dev/sdXYZ` as generic as possible.

Furthermore, I am locked onto your 'it's not a replacement' section of your comments.

Patrick: when/if you think you can crack this puzzle, please let me know.

Only waiting upon the receipt of the game 'rules' ;p

Cheers!


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, August 30, 2020 6:19 PM, Patrick Steinhardt <ps@pks.im> wrote:

> On Sun, Aug 30, 2020 at 03:30:39PM +0000, HardenedArray via Grub-devel wrote:
>
> > As a direct consequence of your valuable `--modules=` input, I have
> > taken the time and attempted to carefully document my entire LUKS2
> > unlocking encrypted /boot process for the benefit of others, similarly
> > situated.
>
> Great to have some documentation of the process, thanks!
>
> > My procedure and comments are posted at:
> > https://aur.archlinux.org/packages/grub-git/ under an intentionally
> > Five Eyes 'unlinked' nick. I know you understand.
> > Please take a moment to review my boot sequence comments within Step
> > 11 and following Step 13, both of which are in concordance with my
> > understanding of the GRUB encrypted /boot unlocking sequence.
> > If either statement needs modification, please let me know, as I do
> > not want others to adopt an incorrect understanding of how both GRUB,
> change between installation, but I guess people can figure that out on
> their own.
>
> > Patrick, I've also noted Eli's further input, immediately below.
> > Given that you now know exactly how I've encrypted / and how I unlock
> > my encrypted: /boot, swap and /, if you can indeed 'hack' a suitable
> > `grub-mkimage` command for me to test, I would be happy to test it.
>
> I currently don't have any available, sorry. I never did the custom
> config thing yet, even though it shouldn't be too hard. I hope to find
> some time in the next few days to give it a test and will report back.
>
> > However, please be sure to tell me whether you intend any such
> > `grub-mkimage` directive to be a REPLACEMENT for `grub-mkconfig` or as
> > a supplemental command.
>
> It's not a replacement of`grub-mkconfig`, but is part of what
> `grub-install` does. `grub-mkimage` will create the executable loaded by
> your bootloader, which includes any pre-loaded modules as well as the
> early boot config. `grub-mkconfig` will create the configuration that's
> used after this early boot step and is loaded when you execute `normal`.
>
> Patrick
>
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

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

[HardenedArray]

Eli,

Sorry if you misunderstood how I decrypted a LUKS2 / from a booted LUKS1 encrypted /boot Arch system.

No CLI, nor initramfs was involved.

I merely booted my LUKS1 encrypted /boot, logged into SDDM, then used KDE's Dolphin to unlock another LUKS2 / partition.  And, of course, grub can boot a non-encrypted /boot with an encrypted LUKS2 /.  Following that LUKS2 boot, Dolphin can be used to unlock a LUKS1 /, but neither approach tests grub unlocking, as far as I know.

++++++++++++++++

Patrick,

Thank you for your follow-up, and understood re:  the ongoing development, and the likely v2.06 LUKS2 support miss.

Also, noted on the additional modules you mentioned.  As far as I can tell, the documentation concerning `grub-install --modules=xxx` is very sparse.  If you know a decent resource, please link it.

Cheers



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, August 28, 2020 4:51 PM, Patrick Steinhardt <ps@pks.im> wrote:

> 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
>
> [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
>
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 817 bytes --]

On 8/28/20 12:51 PM, Patrick Steinhardt wrote:
> 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.

That is what I'd postulated when discussing things with the OP. But I
was having trouble providing clear guidance since I wasn't sure what the
required modules actually are.

> 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.

This sounds like useful guidance.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1601 bytes --]

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

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2234 bytes --]

On 8/28/20 12:35 PM, HardenedArray via Grub-devel wrote:
> 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.

2020-08-17 03:27:30 PM  eschwartz       what I mean to say is, for
testing purposes it's useful to narrow down where grub might be failing
2020-08-17 03:28:16 PM  eschwartz       so instead of re-encrypting /
and /boot with luks2, try adding a new disk, encrypted with luks2, and
see if it can be mounted
2020-08-17 03:28:53 PM  eschwartz       this lets you test, in
isolation, whether grub can decrypt luks2 in general

2020-08-17 03:30:42 PM  eschwartz       if that works, then you can
follow on to the next stage -- seeing if the minimal grubx64.efi (or
BIOS core.img embedded in the MBR) can handle luks2 when unlocking /boot
(which is where extended modules are located)

2020-08-18 02:11:55 PM  h4rd3n3D        eschwartz:  following up from
yesterday, if this a sufficient test from your POV?  From a LUKS1 Arch
encrypted /boot system, I can easily mount a Fedora btrfs LUKS2
encrypted / partition.  The reverse boot and mount case is also true.
Both OSes run grub and can be independently booted.


My assumption was, here, that you performed the fedora mount using the
grub command line. In order to test grub.

Did you instead test this using the Linux initramfs command line? That
would test the linux "cryptsetup" program, a useless test.

> 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...

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1601 bytes --]

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

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 4468 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 3651 bytes --]

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?

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1601 bytes --]

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

[HardenedArray]

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3998 bytes --]