LUKS: GRUB vs. systemd-boot

Help
1

The NixOS wiki page on Full Disk Encryption shows this example config for entering a password on boot:

  boot = {
    loader = {
      efi.canTouchEfiVariables = true;
      grub = {
        enable = true;
        device = "nodev";
        efiSupport = true;
      };
    };
    initrd.luks.devices.cryptroot.device = "...";
  };

My own config, which works fine, uses systemd-boot instead of GRUB. I don’t have a deep understanding of the difference, I just followed the approach I found described in blog posts, and it’s been working for several years.

I would like to understand the difference and implications of using GRUB vs. systemd-boot for booting with a LUKS encrypted device.

For context, an abbreviated view of what lsblk -f prints on my machine:

NAME                   FSTYPE      FSVER    LABEL MOUNTPOINTS
nvme0n1
├─nvme0n1p1            vfat        FAT32    boot  /boot
└─nvme0n1p2            crypto_LUKS 2
  └─root               LVM2_member LVM2 001
    ├─cryptedpool-swap swap        1        swap  [SWAP]
    └─cryptedpool-root ext4        1.0      root  /nix/store
                                                  /
2

I don’t see why it would make any difference. The LUKS prompt happens in stage-1 (initrd), which happens after your boot loader has started the kernel.

A much more important config is whether you have systemd-initrd enabled with boot.initrd.systemd.enable.

3

systemd-boot is a pretty minimal bootloader, so it intentionally doesn’t support reading from an encrypted file system. This means that to let systemd-boot access them, the kernel and initrd files must be stored unencrypted on disk (typically they are copied to the EFI system partition).

GRUB, on the other hand, can read LUKS volumes, so you can keep the kernel and initrd in your encrypted root file system (directly in /nix/store, without copies). GRUB itself will keep its configuration and most modules encrypted in the root file system, while only the so-called “core” image will be stored on the EFI system partition (or master boot record on a non-EFI machine).

The latter is what is usually referred to as “full disk encryption”, because everything except the bootloader is encrypted. But the definition has recently been relaxed somewhat because people don’t consider the kernel and initrd sensitive (or they’re coping with a partially unecrypted disk)

The practical differences are that:

  1. with GRUB you don’t need a large EFI system partition, because everything is stored in the root filesystem (with MBR you don’t need a partition at all).

  2. with GRUB you can safely store secrets in the initrd because they will be encrypted at rest.

  3. with systemd-boot you will have to type your passphrase once, in the initrd. with GRUB once in the boot loader and again in the initrd, unless you set up a key file like shown here.

  4. Until the very latest version, GRUB could only read PBKDF2-based keys and is a lot slower to unlock your disk compared to the linux kernel. So, you may have to reduce the cost of the KDF in order to achieve a reasonable boot time.

  5. with systemd-boot you can’t encrypt everything, but if you trust your TPM (I don’t) you may be able to set up a so-called “measured boot”, which means you can verify the kernel and initrd about to be run haven’t been tampered with.

Note for those who inevitably will want to tell me that encrypting the kernel and initrd is useless and doesn’t protect me from tampering: Yes, thank you, but I like to do it this way, and now GRUB supports dm-verity, so it can detect tampering.

4 Likes