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:
- GRUB unlocks
/boot - Keyfile in
/bootopens/ - Partition for
/bootis listed in/etc/crypttab, with another keyfile to unlock/bootagain from within Linux /bootis 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
/bootand boots into Linux proper, is there any way to access/bootwithout 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
/bootmanually for kernel updates if I want to avoid steps 3 and 4?


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.
As the
fsininitramfssuggests, 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.Besides where you source your rootfs key from (in your case a file in
/boot), the process you described is effectively how encrypted/bootsetups 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
/bootis not necessary). For other threat models, having your rootfs key (presumably LUKS2) inside your encrypted/bootcould significantly decrease security, as GRUB (afaik) only supports LUKS1.Yes, although you could create a hook for your package manager to mount
/booton kernel or initramfs regeneration. Generally, this is less reliable than automounting on startup, as that ensures any change to/bootis 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/bootis a hassle not worth setting up (besides the learning process itself).Thanks for the explanation. And you’re right - it’s was a nice learning exercise and a “satisfying” stopgap while I figure out how to compile either Libreboot, which has a variant of GRUB patched with proper LUKS2 and Argon2 support, or TianoCore, which is rather involved and scantily documented for the old X230 hardware.