5 ms·

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

SomeoneOnTheWeb 3y ago
I used to have a custom NAS with full disk encryption, whose bootloader would spin up a tiny SSH server with very few features, mainly only access to an unlock function that would allow to transmit the encryption passphrase over the said SSH tunnel. Then the SSH connection would be closed by the server and it would startup with the decryption key. That way, it was impossible to access the data physically, but I was still able to reboot the box whenever I wanted without any problem.
- alexvitkov 3y ago
  That's sensible, unlike trusting that TPM+GRUB+dracut+systemd+getty+logind+whatever all work fine and won't leak your key. Rebooting a box is often the easiest way to get something done if you can't be bothered with exotic configs, I just don't believe that remotely rebooting a encrypted box for which you dont have the key is ever a reasonable thing to do, and that's the assumptuon this article is based on.
- teddyh 3y ago
  Might I suggest that Mandos might be a slightly easier version of a solution to that problem? (Disclosure: I am a co-author of Mandos.)
webstrand 3y ago
My experience with kexec has been poor. Every time I kexec, I have to load and unload a bunch of drivers to restore the system to a functional state. Critically i915 sometimes needs to be reloaded after boot to get the display to actually work. And on a VM I had issues with the `cirrus` display driver failing to unload correctly leaving the system unable to boot. Its random and totally unreliable for desktop use. Aside, this is a nice script that prompts for the LUKS password _before_ kexec: https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981871bd7 https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981... it does assume you're using opensuse's naming convention of calling the root partition cr_root. I used this because my bootloader was also encrypted, so rebooting into an initramfs with ssh was impossible.
TeMPOraL 3y ago
> There's no viable reason to reboot a Linux box. Even cosmic rays flipping bits in your RAM in a way that can't be recovered from?
- alexvitkov 3y ago
  If that's a big issue for you consider using ECC memory, or even better - colocating your servers in an abandoned mine.
jmetzmeier 3y ago
What about libc updates? If you need to restart effectively every process on the system anyways, why not reboot?
- PlutoIsAPlanet 3y ago
  Only rolling distros should be shipping mid-release cycle updates that break libc compatibility. It's not a normal thing for release-based distributions where userspace<>userspace compatibility is nearly assured during a release.
  - jmetzmeier 3y ago
    Compatibility does not need to break to require a restart of a process. Linux does not have a mechanism that tells processes to reload their shared libraries when they are modified on disk. When a .so file is updated on disk, for example a minor update for a security vulnerability, all processes using that library need to be restarted to utilize that new update. If you're not restarting processes on these upgrades, you are not getting their benefits.This is why tools like dnf-tracer-plugin exist, but it's often just as easy to reboot, especially if you built your systems to be fault tolerant.
- alexvitkov 3y ago
  static link musl

SomeoneOnTheWeb 3y ago

I used to have a custom NAS with full disk encryption, whose bootloader would spin up a tiny SSH server with very few features, mainly only access to an unlock function that would allow to transmit the encryption passphrase over the said SSH tunnel. Then the SSH connection would be closed by the server and it would startup with the decryption key. That way, it was impossible to access the data physically, but I was still able to reboot the box whenever I wanted without any problem.

alexvitkov 3y ago
That's sensible, unlike trusting that TPM+GRUB+dracut+systemd+getty+logind+whatever all work fine and won't leak your key. Rebooting a box is often the easiest way to get something done if you can't be bothered with exotic configs, I just don't believe that remotely rebooting a encrypted box for which you dont have the key is ever a reasonable thing to do, and that's the assumptuon this article is based on.
teddyh 3y ago
Might I suggest that Mandos might be a slightly easier version of a solution to that problem? (Disclosure: I am a co-author of Mandos.)

webstrand 3y ago

My experience with kexec has been poor. Every time I kexec, I have to load and unload a bunch of drivers to restore the system to a functional state. Critically i915 sometimes needs to be reloaded after boot to get the display to actually work. And on a VM I had issues with the `cirrus` display driver failing to unload correctly leaving the system unable to boot. Its random and totally unreliable for desktop use. Aside, this is a nice script that prompts for the LUKS password _before_ kexec: https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981871bd7 https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981... it does assume you're using opensuse's naming convention of calling the root partition cr_root. I used this because my bootloader was also encrypted, so rebooting into an initramfs with ssh was impossible.

TeMPOraL 3y ago

> There's no viable reason to reboot a Linux box. Even cosmic rays flipping bits in your RAM in a way that can't be recovered from?

alexvitkov 3y ago
If that's a big issue for you consider using ECC memory, or even better - colocating your servers in an abandoned mine.

jmetzmeier 3y ago

What about libc updates? If you need to restart effectively every process on the system anyways, why not reboot?

PlutoIsAPlanet 3y ago
Only rolling distros should be shipping mid-release cycle updates that break libc compatibility. It's not a normal thing for release-based distributions where userspace<>userspace compatibility is nearly assured during a release.
- jmetzmeier 3y ago
  Compatibility does not need to break to require a restart of a process. Linux does not have a mechanism that tells processes to reload their shared libraries when they are modified on disk. When a .so file is updated on disk, for example a minor update for a security vulnerability, all processes using that library need to be restarted to utilize that new update. If you're not restarting processes on these upgrades, you are not getting their benefits.This is why tools like dnf-tracer-plugin exist, but it's often just as easy to reboot, especially if you built your systems to be fault tolerant.
alexvitkov 3y ago
static link musl