Since #21, enabling both disk encryption and swap results in failing to boot. This is because we've removed crypto_keyfile.bin
from initrd to resolve GHSA-3rvf-24q2-24ww. Without that keyfile present in initrd, it is unable to decrypt the swap partition, and boot fails.
It's easy enough to fix for UEFI boot: Simply remove this line:
|
boot.initrd.luks.devices."@@swapdev@@".keyFile = "/crypto_keyfile.bin"; |
NixOS will ask for your LUKS passphrase in initrd, and it will reuse that passphrase between both the root and swap partitions.
BIOS boot, however, is a different story, due to the use of Grub's cryptodisk. In BIOS boot, Grub cryptodisk is the first to ask for the LUKS passphrase, and it loads the kernel and initrd from the encrypted root partition. Before #21, the initrd contained crypto_keyfile.bin
, which allowed the kernel to unlock the root fs and the swap partition without asking for the passphrase a second time. This was secure because the initrd was stored in the encrypted root partition. On UEFI, this was very much not secure, because the initrd was stored on the unencrypted ESP (hence why #21 happened).
To continue using cryptodisk, we would need to revive storing crypto_keyfile.bin
in initrd, but only for BIOS boot with initrd on encrypted storage. The calamares documentation seems to suggest that cryptodisk is preferable, but I (and I think many other NixOS developers) think this is a bad suggestion, and it would be better to use an unencrypted /boot
partition, much like the ESP in UEFI boot.
Relatedly, due to the implementation of #21, you are now prompted for the LUKS passphrase twice when BIOS booting without swap; once for Grub, and once for initrd.
Finally, I'm sure other bugs of this kind exist when the user chooses manual partitioning with encryption involved. I haven't begun to analyze this yet.