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
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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
fs
ininitramfs
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.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.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).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.