bug#55723: Full disk encryption with grub-efi and LUKS2
Hello Josselin and Lars-Dominik Josselin Poiret via Bug reports for GNU Guix writes: [...] >> 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: https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html [...] > 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 signature.asc Description: PGP signature
bug#55723: Full disk encryption with grub-efi and LUKS2
Hello Lars, Lars-Dominik Braun writes: > 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. [1] https://lists.gnu.org/archive/html/grub-devel/2021-12/msg00076.html Best, -- Josselin Poiret
bug#55723: Full disk encryption with grub-efi and LUKS2
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 [1] https://logs.guix.gnu.org/guix/2022-05-27.log#111808 [2] https://wiki.archlinux.org/title/GRUB#LUKS2 [3] https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot
