|
|
|
|
|
by sillystuff
98 days ago
|
|
> As the decrypted key is in memory before the reboot, can’t it just be written to a know location in memory and have kexec be instructed to read it early on? I set up what you are suggesting (sort of anyway[1]) on a personal VPS to reboot after updates, that require one. I just generate an initrd in tmpfs that contains a keyfile[2] and kexec with that ephemeral initrd; The newest kernel can be found by looking at what the /boot/vmlinuz symlink points to. Been running this for years. It is 100% reliable, and simple. And, for the purposes of this box, secure enough. For remote unlocks from initial power on, Debian has had that since forever using keyscripts and dropbear in the initrd. [1] You could pull the key from memory, and use that to unlock the disk from within the generated initrd, but it would be more work than just setting up a keyfile in advance. It was my first thought as well. [2] Easiest way was to use a mount namespace to use a diff crypttab file that points to the keyfile, since cannot specify crypttab location when creating the initrd. E.g., unshare --mount sh -c "mount --bind $CRYPTTAB_KEXEC $CRYPTTAB; mkinitramfs -o $kexec_initramfs $kernel"
(mkinitramfs is usually wrapped by update-initramfs, but calling it directly allows specifying a location) |
|