Full disk encryption with grub-efi and LUKS2

  • Open
  • quality assurance status badge
Details
3 participants
  • Josselin Poiret
  • Giovanni Biscuolo
  • Lars-Dominik Braun
Owner
unassigned
Submitted by
Lars-Dominik Braun
Severity
normal
L
L
Lars-Dominik Braun wrote on 30 May 2022 12:07
(address . bug-guix@gnu.org)
YpSXc6binZlmdwdd@noor.fritz.box
Hi,

I followed the manual to manually install Guix with full disk encryption
using LUKS2 and PBKDF2. However this leaves me with an unbootable system,
stuck at Grub’s rescue prompt, because `grub-install` apparently does
not know how to detect a LUKS2 target and therefore does not include
the modules required to open the encrypted volume in the EFI image. See
[1].

I managed to manually create a core.img with the help of ArchLinux’
Wiki[2] (see also [3]), boot into the system and reconfigure with a
modified bootloader:

---snip---
(define install-grub-efi-mkimage
"Create an Grub EFI image with included cryptomount support for luks2,
which grub-install does not handle yet."
#~(lambda (bootloader efi-dir mount-point)
(when efi-dir
(let ((grub-mkimage (string-append bootloader "/bin/grub-mkimage"))
;; Required modules, YMMV.
(modules (list "luks2" "part_gpt" "cryptodisk" "gcry_rijndael" "pbkdf2" "gcry_sha256" "ext2"))
(prefix (string-append mount-point "/boot/grub"))
;; Different configuration required to set up a crypto
;; device. Change crypto_uuid to match your output of
;; `cryptsetup luksUUID /device`.
;; XXX: Maybe cryptomount -a could work?
(config #$(plain-file "grub.cfg" "set crypto_uuid=755e547f78f44dc38dab58399e1780a6
cryptomount -u $crypto_uuid
set root=crypto0
set prefix=($root)/boot/grub
insmod normal
normal"))
(target-esp (if (file-exists? (string-append mount-point efi-dir))
(string-append mount-point efi-dir)
efi-dir)))
(apply invoke (append
(list
grub-mkimage
"-p" prefix
"-O" "x86_64-efi"
"-c" config
"-o" (string-append target-esp "/EFI/Guix/grubx64.efi"))
modules))))))

(define grub-efi-bootloader-luks2
(bootloader
(inherit grub-efi-bootloader)
(name 'grub-efi-luks2)
(installer install-grub-efi-mkimage)))
---snap---

Supposedly there are also patches for grub-mkimage, but maybe we can
include a workaround like the above by default until then or remove the
section about LUKS2 entirely?

Cheers,
Lars

J
J
Josselin Poiret wrote on 31 May 2022 12:44
87fskqgew4.fsf@jpoiret.xyz
Hello Lars,

Lars-Dominik Braun <lars@6xq.net> writes:

Toggle quote (19 lines)
> Hi,
>
> I followed the manual to manually install Guix with full disk encryption
> using LUKS2 and PBKDF2. However this leaves me with an unbootable system,
> stuck at Grub’s rescue prompt, because `grub-install` apparently does
> not know how to detect a LUKS2 target and therefore does not include
> the modules required to open the encrypted volume in the EFI image. See
> [1].
>
> I managed to manually create a core.img with the help of ArchLinux’
> Wiki[2] (see also [3]), boot into the system and reconfigure with a
> modified bootloader:
>
> [...]
>
> Supposedly there are also patches for grub-mkimage, but maybe we can
> include a workaround like the above by default until then or remove the
> section about LUKS2 entirely?

Thank you for posting this bug and sorry for taking so long with this.
I'd suggest that we instead add a warning that `/boot/` must be
unencrypted for LUKS2+GRUB to work for now, possibly pointing to this
bug.

Let me explain the whole situation so that we have good summary of the
LUKS2+GRUB situation:

* GRUB the bootloader itself supports unlocking LUKS2 cryptodisks, with
its `luks2` module, that we load via `insmod luks2` in the grub.cfg.
It doesn't contain support for Argon2i yet, so only the PBKDF2 key
derivation function can be used, which is unfortunately not the
default for cryptsetup.

* Now, while the `luks2` module lets you unlock your disk, you have the
usual chicken-and-egg problem: GRUB modules are stored in
/boot/grub/. If this resides on a LUKS2 drive, then you'd be out of
luck! However, this is a common issue with bootloaders, and GRUB
allows embedding modules inside its own image, so that some modules
are preloaded. You can either create the image manually using
grub-mkimage, or grub-install can take care of it for you, by
detecting which modules should be embedded using a user-space version
of GRUB. This is where the LUKS2 support isn't finished yet: the
userspace utilities don't recognize LUKS2, and will thus not try to
include luks2 and friends if /boot/grub/ is on such a device.

The crux of the issue is that when running in user-space, GRUB cheats by
"pretending" to mount the device itself (called cheatmounting), and
actually relays all reads to the underlying dm-crypt device! For LUKS1,
this works well, but LUKS2 can have multiple keyslots and data segments,
each with different algorithms, and since we don't know which keyslot
was used to unlock the device, we won't know which GRUB crypto modules
to include. My approach at [1] is to ask device-mapper directly, but
there are also other patches trying various other methods, and the
consensus now seems to be that each patch does one thing well and that
we should combine all of the good parts.

In any case, I can send a documentation patch to warn about the current
situation later today.


Best,
--
Josselin Poiret
J
J
Josselin Poiret wrote on 31 May 2022 16:36
[PATCH] doc: Warn about LUKS2-encrypted boot not working with GRUB.
20220531143637.22201-1-dev@jpoiret.xyz
* doc/guix.texi (Disk Partitioning): Do it.
---
doc/guix.texi | 5 +++++
1 file changed, 5 insertions(+)

Toggle diff (18 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index 1666466958..c7f6070ced 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2560,6 +2560,11 @@ for @command{cryptsetup luksFormat}. You can check which key derivation
function is being used by a device by running @command{cryptsetup
luksDump @var{device}}, and looking for the PBKDF field of your
keyslots.
+
+Note also that having @file{/boot/} reside on a LUKS2-encrypted device
+is currently unsupported because of a GRUB 2.06 bug, see
+@url{https://issues.guix.gnu.org/55723, bug #55723}. The graphical
+installer defaults to LUKS1 for this reason.
@end quotation
Assuming you want to store the root partition on @file{/dev/sda2}, the
--
2.36.0
G
G
Giovanni Biscuolo wrote on 2 Jun 2022 15:44
Re: bug#55723: Full disk encryption with grub-efi and LUKS2
87zgiv5ged.fsf@xelera.eu
Hello Josselin and Lars-Dominik

Josselin Poiret via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

[...]

Toggle quote (9 lines)
>> Supposedly there are also patches for grub-mkimage, but maybe we can
>> include a workaround like the above by default until then or remove the
>> section about LUKS2 entirely?
>
> Thank you for posting this bug and sorry for taking so long with this.
> I'd suggest that we instead add a warning that `/boot/` must be
> unencrypted for LUKS2+GRUB to work for now, possibly pointing to this
> bug.

As Josselin wrote in the proposed patch, actually /boot/ on LUKS1 is
working well

In case it is helpful, it's possible to "Downgrade" a LUKS2 volume to
LUKS1, I found this guide useful:

[...]

Toggle quote (5 lines)
> to include. My approach at [1] is to ask device-mapper directly, but
> there are also other patches trying various other methods, and the
> consensus now seems to be that each patch does one thing well and that
> we should combine all of the good parts.

Thank you very much for the update and the work on GRUB!

Please is there any upstream (GRUB) bug report we can point to in this
one so we can follow the situation and know when upsstream will release
the patch?

[...]

Happy hacking! Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmKYvroMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSsmgP/1vijdwVrU9BqnuqD25jBH5FhgeGe5evfsNyGAA/
lbX6H+kA/nqxJEhPeVyWFim8RhCuPT9qxeExmq424bUfK+LwV9If0WzUq7q7MIOj
Lw2G990G10kup2qTcCJHEXG7hdbl83yEv8SQD9AFA9iwdIysEyi9DFh+CJj4xQwv
6Ghzx9FOu8NtzrL3t+Sh6+APEBzoFDpu2NsKE8CUFDs0m/NDMS4fx8vqhbj040xk
9fyVD5NyEMmaLAlsbgQlAL/r6eyxaxKqwVsSRMVUYYJy5u+VGQqixxYOrT3wB0HA
y1Mb5KR6Htn9/0bzJYgJPKzwAsSEjz/dx14pGRAu4lYktkEXYHzyr2N0BxWfuqeQ
k4eVfJkfE9PQmmuWlxLboaTg6JIGqF9S1ouNuYG6BIbDmO6lmomlerTNWzZYppmt
JoJj6zMlX0/RJJ0FhhBxrgeGX9Dp9RHrUZ3Bwowq38q9jrgBWi8e5f6xt+Zbg74b
GJNoT0zxPWXZHjQ/+1OqlX48YISezjOUFpME5IQP5IKYuTcFo0WomVdtF9hG7ED/
bl9ptSraS7T8JtIgqQpZMFGvPUnsIQsYq8Eb9YsHm0qZWcLjJu1aP6lLSpN/W6hk
sxUQvzSw79FwwilIx4dwSFodOv5ETnDnLJK8JjT3E10IVHbWcTeI9+AH+jFiXXyX
tDMg
=21df
-----END PGP SIGNATURE-----

L
L
Lars-Dominik Braun wrote on 5 Jun 2022 12:38
Re: [PATCH] doc: Warn about LUKS2-encrypted boot not working with GRUB.
(name . Josselin Poiret)(address . dev@jpoiret.xyz)(address . 55723@debbugs.gnu.org)
YpyHizsrL5dt83L2@noor.fritz.box
Hi Josselin,

Toggle quote (4 lines)
> +Note also that having @file{/boot/} reside on a LUKS2-encrypted device
> +is currently unsupported because of a GRUB 2.06 bug, see
> +@url{https://issues.guix.gnu.org/55723, bug #55723}. The graphical
> +installer defaults to LUKS1 for this reason.
instead of adding yet another exception, why not just document how
to do it with LUKS1, which – as I understand it – works without
these quirks?

Cheers,
Lars
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 55723@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 55723
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch