On Tue, 25 Mar 2025 23:01:02 +0800, 45mg wrote: > > Hilton Chain <hako@ultrarare.space> writes: > > > On Tue, 25 Mar 2025 20:12:25 +0800, > > 45mg wrote: > >> > >> "Thomas Ieong" <th.ie...@free.fr> writes: > >> > >> > I remember that some years ago we could not use LUKS 2, has the situation > >> > improved? > >> > >> I'm writing this from Guix System installed on an LUKS 2 volume. So, > >> yes, it works now. GRUB also supports `--pbkdf argon2id` now, so you > >> don't have to worry about that insecurity [1] anymore. > > > > GRUB doesn't support Argon2 at the moment. > > Not really sure how I'm booting then. I see '# PBKDF argon2id, ...' in > the output of `sudo cryptsetup status --debug myrootvolname`.
Which GRUB variant are you using? There exists an unlikely to be merged patch series for Argon2 support. > IIRC, the issue was that libgcrypt didn't support argon2*. A quick > search of the commit logs seems to suggest this has changed since 2022: > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git&a=search&h=HEAD&st=commit&s=argon2 GRUB uses a vendored version of libgcrypt[1]. > >> The problem is that you still need GRUB to decrypt the volume before you > >> can boot, and GRUB's decryption is really slow (takes over a minute, > >> versus a few seconds after booting the kernel). > >> > >> What most distributions do is use something like `ukify` to generate a > >> bootable UEFI image that has includes the required crypto modules. There > >> is an open patch series that would add this to Guix [2], but it hasn't > >> been touched in a long time (it was split off from a larger rewrite of > >> the bootloader subsystem [3], which also hasn't been touched in a > >> while). > > > > UKI bootloader doesn't suits the multiple generation model well, the > > implementation depends on the reliablity of EFI firmware too much. > > Could you elaborate, or link to a resource/past message/whatever > explaining this? I once used UKI, but at one point the updated boot entries didn't persist in a subsequent reboot. Then I changed my mind to not expect much from the firmware implementation and switched to grub-efi-removable-bootloader instead. > If I understand correctly, the main issue here is that the initrd > doesn't know how to mount encrypted partitions. There are solutions to > this other than UKIs, such as Arch's mkinitcpio: > https://wiki.archlinux.org/title/Dm-crypt/System_configuration#mkinitcpio Our initrd knows how to decrypt. It's GRUB that needs to decrypt then find its configuration and kernel + initrd first. --- [1]: https://git.savannah.gnu.org/cgit/grub.git/log/grub-core/lib/libgcrypt
