3 ms·

Why is this needed at all? 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 instruct

by koolba 7mo ago

Why is this needed at all? 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?

teddyh 7mo ago
You’re assuming a controlled reboot. Mandos was initially created to deal with intermittent power failures. It’s also good for kernel panics.
- koolba 7mo ago
  Oh for sure something is needed for a full start from zero. But the much more common case for a computer with backup power is regular restarts after applying patches that require a reboot. Would be much more pleasant for that to work out of the box with no manual interaction at all.
  - PunchyHamster 7mo ago
    There is plenty of cases of cold boot in datacenter. Also most distros don't support using kexec for kernel upgrades anyway.
sillystuff 7mo 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)

by koolba 7mo ago

Why is this needed at all? 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?

teddyh 7mo ago

You’re assuming a controlled reboot. Mandos was initially created to deal with intermittent power failures. It’s also good for kernel panics.

koolba 7mo ago
Oh for sure something is needed for a full start from zero. But the much more common case for a computer with backup power is regular restarts after applying patches that require a reboot. Would be much more pleasant for that to work out of the box with no manual interaction at all.
- PunchyHamster 7mo ago
  There is plenty of cases of cold boot in datacenter. Also most distros don't support using kexec for kernel upgrades anyway.

sillystuff 7mo 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)