Weird GRUB decryption behavior with LVM

[powerjungle]

My setup consists of 2 LVM partitions for /boot and root. Both are encrypted, /boot with LUKS1 and root with LUKS2. My GRUB version is 2.06-13+deb13u1 and I am running Debian Testing.

I correctly get a password prompt for lvm/boot, if I enter it incorrectly I have to reboot which is expected. When I enter it correctly, I get a second password prompt for lvm/root, still in GRUB, initramfs isn't started yet. When I input anything in the second prompt, it continues and starts booting. I expected it to complain about about a wrong password. Even just directly pressing enter works.

When I try to manually open the partitions using cryptsetup, it accepts only the correct password in any case.

I tried looking into the spec and the code, but I cannot find an explanation why this is the current behavior.

cryptsetup luksDump gives me "Tokens:" which seems empty, because is followed directly by "Digests:"

I am probably missing something and not understanding the whole idea.

[Aki]

Hello,

My setup consists of 2 LVM partitions for /boot and root. Both are encrypted, /boot with LUKS1 and root with LUKS2. My GRUB version is 2.06-13+deb13u1 and I am running Debian Testing.

I correctly get a password prompt for lvm/boot, if I enter it incorrectly I have to reboot which is expected. When I enter it correctly, I get a second password prompt for lvm/root, still in GRUB, initramfs isn't started yet. When I input anything in the second prompt, it continues and starts booting. I expected it to complain about about a wrong password. Even just directly pressing enter works.

The boot loader (grub) should only decrypt the boot partition (if it is different from the root partition).

The root partition should be decrypted by the Linux kernel, which is loaded into memory by grub.

You can easily verify it reading system logs.

[powerjungle]

The root partition should be decrypted by the Linux kernel, which is loaded into memory by grub.

It is and I'm using a keyfile to avoid typing the password twice. But then why do I get a password prompt for lvm/root? It's the same prompt text as the one for boot, so it seems to be from GRUB.

I forgot to mention that my system boots properly, my question is only regarding this second password prompt which seems to not be doing anything.

[Aki]

Take a look at system logs.

[vng2022]

Also please look if you have in your /etc/default/grub a line with GRUB_ENABLE_CRYPTODISK=y
If yes, then comment it out, backup /boot/grub/grub.cfg and run sudo update grub

[powerjungle]

Also please look if you have in your /etc/default/grub a line with GRUB_ENABLE_CRYPTODISK=y

I do, because my /boot is encrypted. Without it, how will GRUB decrypt /boot?

Take a look at system logs.

I did and what am I looking for exactly?

Code: Select all

Dec 05 19:54:55 pc systemd[1]: Starting systemd-cryptsetup@debian\x2droot_crypt.service - Cryptography Setup for debian-root_crypt...
Dec 05 19:54:55 pc systemd[1]: Found device dev-disk-by\x2duuid-49b4c835\x2d84e2\x2d449f\x2da07b\x2da71038dac475.device - /dev/disk/by-uuid/49b4c835-84e2-449f-a07b-a71
038dac475.
Dec 05 19:54:55 pc systemd[1]: Starting systemd-cryptsetup@debian\x2dboot_crypt.service - Cryptography Setup for debian-boot_crypt...

[Aki]

Hello,

I did and what am I looking for exactly?

Code: Select all

Dec 05 19:54:55 pc systemd[1]: Starting systemd-cryptsetup@debian\x2droot_crypt.service - Cryptography Setup for debian-root_crypt...
Dec 05 19:54:55 pc systemd[1]: Found device dev-disk-by\x2duuid-49b4c835\x2d84e2\x2d449f\x2da07b\x2da71038dac475.device - /dev/disk/by-uuid/49b4c835-84e2-449f-a07b-a71
038dac475.
Dec 05 19:54:55 pc systemd[1]: Starting systemd-cryptsetup@debian\x2dboot_crypt.service - Cryptography Setup for debian-boot_crypt...

Are there log messages about the pass-phrase or the encryption key used by systemd-cryptsetup to open the encrypted partition ?

Are you using the same key / pass-phrase for the boot and root encrypted partitions ?

According to systemd-cryptsetup@.service manual page:

[..]
At early boot and when the system manager configuration is reloaded, /etc/crypttab is translated into systemd-cryptsetup@.service units by systemd-cryptsetup-generator(8).

In order to unlock a volume a password or binary key is required. systemd-cryptsetup@.service tries to acquire a suitable password or binary key via the following mechanisms, tried in order:

1.If a key file is explicitly configured (via the third column in /etc/crypttab), a key read from it is used. If a PKCS#11 token, FIDO2 token or TPM2 device is configured (using the pkcs11-uri=, fido2-device=, tpm2-device= options) the key is decrypted before use.

2.If no key file is configured explicitly this way, a key file is automatically loaded from /etc/cryptsetup-keys.d/volume.key and /run/cryptsetup-keys.d/volume.key, if present. Here too, if a PKCS#11/FIDO2/TPM2 token/device is configured, any key found this way is decrypted before use.

3.If the try-empty-password option is specified it is then attempted to unlock the volume with an empty password.

4.The kernel keyring is then checked for a suitable cached password from previous attempts.

5.Finally, the user is queried for a password, possibly multiple times, unless the headless option is set.

If no suitable key may be acquired via any of the mechanisms describes above, volume activation fails.

Therefore, if the operative system is decrypting the root partition without asking you for the pass-phrase (after decrypting the encrypted boot partition), the explanation should be in one of the previous listed five mechanisms.