4 ms·

The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters t

The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters their password. This would require some cooperation with the login program, and maybe with the user app, so it's hard to organize in the Linux world. I think something like this is available on Windows, but I'm not sure. It would be also great if you could use the graphical login (greeter) to decrypt your disk (at boot or after sleep). I think some of the neccessary infrastructure would be the same for both features.

api 5y ago
Why can’t the kernel just generate a random secret at boot and encrypt swap and hibernate files automatically? MacOS does this. I thought Linux did already. With AES in hardware it’s not much more costly than memcpy.
- jchw 5y ago
  This is done for Linux Lockdown. For memfd_secret, it might not be considered good enough; I think the memory needs to be evicted.
  - api 5y ago
    What is the threat model for this? If it’s a highly advanced attacker with physical access not even that is good enough. The best we can do is a true hardware enclave.
josephcsible 5y ago
> The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters their password A third option: do neither, and just accept that hibernation temporarily drops the security guarantees that the feature usually offers.
- Arrath 5y ago
  I would think that a temporary loss of security guarantee is tantamount to a complete loss of security guarantee.
  - josephcsible 5y ago
    Isn't this built to protect against stuff like Spectre, not arbitrary kernel code execution? Couldn't the order of operations be suspend all user processes, do CPUID on every core (i.e., stop all speculative execution), unprotect the memory, save everything to disk, and then the reverse to wake back up?
yencabulator 5y ago
Here's how your typical Linux desktop app can be notified of an upcoming hibernation, and prepare accordingly: https://www.freedesktop.org/wiki/Software/systemd/inhibit/ https://www.freedesktop.org/wiki/Software/systemd/inhibit/ (I'm assuming hibernation is not a requirement outside of the desktop space.)

api 5y ago

Why can’t the kernel just generate a random secret at boot and encrypt swap and hibernate files automatically? MacOS does this. I thought Linux did already. With AES in hardware it’s not much more costly than memcpy.

jchw 5y ago
This is done for Linux Lockdown. For memfd_secret, it might not be considered good enough; I think the memory needs to be evicted.
- api 5y ago
  What is the threat model for this? If it’s a highly advanced attacker with physical access not even that is good enough. The best we can do is a true hardware enclave.

josephcsible 5y ago

> The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters their password A third option: do neither, and just accept that hibernation temporarily drops the security guarantees that the feature usually offers.

Arrath 5y ago
I would think that a temporary loss of security guarantee is tantamount to a complete loss of security guarantee.
- josephcsible 5y ago
  Isn't this built to protect against stuff like Spectre, not arbitrary kernel code execution? Couldn't the order of operations be suspend all user processes, do CPUID on every core (i.e., stop all speculative execution), unprotect the memory, save everything to disk, and then the reverse to wake back up?

yencabulator 5y ago

Here's how your typical Linux desktop app can be notified of an upcoming hibernation, and prepare accordingly: https://www.freedesktop.org/wiki/Software/systemd/inhibit/ https://www.freedesktop.org/wiki/Software/systemd/inhibit/ (I'm assuming hibernation is not a requirement outside of the desktop space.)