this post was submitted on 25 Sep 2025
23 points (92.6% liked)

Linux

58611 readers
1037 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
 

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?
top 4 comments
sorted by: hot top controversial new old
[–] deadcade@lemmy.deadca.de 5 points 4 days ago (1 children)

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).

[–] monovergent@lemmy.ml 1 points 4 days ago

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.

[–] tla@lemmy.world 4 points 4 days ago (1 children)

Is there a reason UEFI Secure Boot with custom keys can't be used?

[–] monovergent@lemmy.ml 4 points 4 days ago* (last edited 4 days ago)

This was the way on my UEFI desktop, but I gave up getting UEFI to work with Coreboot on the X230, so I settled for the next best thing.