When I moved to Coreboot, I also elected to encrypt my /boot partition, which is decrypted by the GRUB payload of Coreboot. I mostly worked on this by trial-and-error, which resulted in the workflow:

  1. GRUB unlocks /boot
  2. Keyfile in /boot opens /
  3. Partition for /boot is listed in /etc/crypttab, with another keyfile to unlock /boot again from within Linux
  4. /boot is mounted via /etc/fstab

Steps 3 and 4 always seemed inelegant to me, but after doing systemd-analyze, I realized how much those steps consume when booting (9 sec).

My questions:

  • After GRUB unlocks /boot and boots into Linux proper, is there any way to access /boot without unlocking again?
  • Are the keys discarded when initramfs hands off to the main Linux system?
  • If GRUB supports encrypted /boot, was there a ‘correct’ way to set it up?
  • Or am I left with mounting /boot manually for kernel updates if I want to avoid steps 3 and 4?
  • deadcade@lemmy.deadca.de
    4·
    2 days ago

    After GRUB unlocks /boot and boots into Linux proper, is there any way to access /boot without unlocking again?

    No. The “unlocking” of an encrypted partition is nothing more than setting up decryption. GRUB performs this for itself, loads the files it needs, and then runs the kernel. Since GRUB is not Linux, the decryption process is implemented differently, and there is no way to “hand over” the “unlocked” partition.

    Are the keys discarded when initramfs hands off to the main Linux system?

    As the fs in initramfs suggests, it is a separate filesystem, loaded in ram when initializing the system. This might contain key files, which can be used by the kernel to decrypt partitions during boot. After booting (pivoting root), the keyfiles are unloaded, like the rest of initramfs (afaik, though I can’t directly find a source on this rn). (Simplified explanation) The actual keys are actively used by the kernel for decryption, and are not unloaded or “discarded”, these are kept in memory.

    If GRUB supports encrypted /boot, was there a ‘correct’ way to set it up?

    Besides where you source your rootfs key from (in your case a file in /boot), the process you described is effectively how encrypted /boot setups work with GRUB.

    Encryption is only as strong as the weakest link in the chain. If you want to encrypt your drive solely so a stolen laptop doesn’t leak any data, the setup you have is perfectly acceptable (though for that, encrypted /boot is not necessary). For other threat models, having your rootfs key (presumably LUKS2) inside your encrypted /boot could significantly decrease security, as GRUB (afaik) only supports LUKS1.

    Or am I left with mounting /boot manually for kernel updates if I want to avoid steps 3 and 4?

    Yes, although you could create a hook for your package manager to mount /boot on kernel or initramfs regeneration. Generally, this is less reliable than automounting on startup, as that ensures any change to /boot is always made to the boot partition, not accidentally to a directory om your rootfs, even outside the package manager.

    If you require it, there are “more secure” ways of booting than GRUB with encrypted /boot, like UKIs with secure boot (custom keys). If you only want to ensure a stolen laptop doesn’t leak data, encrypted /boot is a hassle not worth setting up (besides the learning process itself).