Christine Lemmer-Webber <[email protected]> wrote: > Hello all!
Hi! Thanks for writing this mail! I also spent some time thinking about how we can improve Guix's full disk encryption setup. Some thoughts below. > But a universally agreed upon issue at that group was: booting on a > non-x86 system isn't great. In fact, it's not even great for full > encrypted boot on the x86 world, we're just *used* to it being not > great. I don't use Guix on non-x86 devices, so the comments below mostly refer to the parts of your email that are also applicable to x86-based systems. > - It's painful with full disk encryption even then, because you have to > type your passphrase twice. And the first time you type it you're > stuck waiting for what feels like ages to find out if you entered it > right or not, and if you haven't, you have to start all over. And if > you have, you have to enter it *again*, with a "three strikes till a > rescue REPL" situation, which if you hit that it's the absolute worst > because then you have to start all over again. A workaround for this issue, which has been available since last year, is adding an extra keyslot to the LUKS volume to enable unlocking with a keyfile. This keyfile is included in the encrypted initramfs and used to unlock the volume from it, without requiring an additional passphrase prompt. As such, you have to enter the prompt only once in GRUB [1, 2]. [1]: https://codeberg.org/guix/guix/commit/d082312ef7adfea69c79d30ef947817b39832161 [2]: https://codeberg.org/guix/guix/commit/086850e5b2b4a1744565fe83624d256524b64a49 > - But also due to the bootloader hacks where GRUB decrypts the disk for > you (albeit slowly) for full disk encryption we rely on, this also > means that we really don't have a path to full disk encryption for > non-x86 devices at all. Yes, GRUB's implementation is awfully slow (I assume it isn't HW-accelerated). It becomes even worse when using multiple keyslots (e.g., as in the setup described above), as GRUB tries to unlock both keyslots if you mistype your passphrase. Hence, it will be quite a while before you can try again. Generally, the LUKS implementation in GRUB is always a bit behind what is provided and used by cryptsetup. For example, LUKS2 wasn't supported for a long time [3] and only a limited number of key derivation functions are implemented. Most importantly, argon2 isn't supported [4], which is used by cryptsetup by default these days [5]. In my view, unlocking of LUKS volumes with GRUB is not a sane default. [3]: https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755 [4]: https://www.gnu.org/software/grub/manual/grub/html_node/cryptomount.html#cryptomount [5]: https://gitlab.com/cryptsetup/cryptsetup/-/commit/db775417909db0f0b07168d07fdf8813e3ca94fe > What's the path out? Is there a glorious future with full disk > encryption, entering your passphrase just *once*, and the ability to > select which generation to boot from for everyone? > > I don't know the answers myself, I can speculate on a few: > > - Have an unencrypted /boot which gets "splatted" to, but then we switch > the kernel or something with kexec (somewhat suboptimal and kinda > risky feeling) I use an unencrypted /boot myself; it enables me to unlock with the cryptsetup LUKS implementation, thereby mitigating the issues outlined above. To do this with Guix, I implemented a hacky Guix bootloader abstraction that copies all files referenced in the GRUB configuration from the store to /boot. For more information, refer to: https://notes.8pit.net/notes/mwpp.html Using an unencrypted /boot is not inherently more insecure than the current setup, assuming that you don't require confidentiality for vmlinuz and the other files referenced in the GRUB configuration. Integrity is also not achieved by the current setup, as a malicious actor can also compromise the unencrypted GRUB bootloader currently. If you want integrity you need secure boot, TPM, et cetera. > - What does Nix do? I am not an expert on Nix but my understanding is that Nix also uses an unencrypted /boot and copies files required by Grub from the store to it. IIRC this is done in the install-grub.pl Perl script that they provide for this purpose [6]. [6]: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/loader/grub/install-grub.pl Greetings, Sören
