Hacker News Reader

Comment by est31 | Hacker News Reader

I wonder about the swap behaviour. If it's going to go to swap, it means the secret might remain on the hard disk. If the swap is on an SSD, you might not have a way to securely delete it at all due to the wear levelling layer. If it's not going to swap, you piss off the people with laptops who want hibernation. You might need to encrypt it and store the key in the TPM or something. Not sure if that's implemented though.

View on HN

The article says that hibernation is completely disabled when a secret memory area is active and the memory area is locked into RAM. They designed it so the secret would never be written to persistent storage.

As noted in other comments it is locked in memory and hibernation is disabled, but generally encrypted swap is even easier to use than encrypted FS - a key can be generated on each boot (one-time random swap key is not compatible with hibernation though, for this you'd need a fixed one).

There's a whole section on the memory implications: "Another change, which created a bit of controversy over the life of the patch, disables hibernation when a secret memory area is active."

Based on that, I doubt they ignored the problem of swap space. My guess is that the region of memory is designated unswappable, as was already possible before.

Ideally there would be a way for the OS to signal that it's going to hibernate, so that the application can get rid of the secret stuff (overwrite with zeroes etc) and go to a state that, when back from hibernation, would ask for a password again.

Or even, disable this when hibernating to a swap inside an encrypted luks partition (which also asks for a password when it wakes up)

Perhaps a reasonable way would be to have a memfd_secret() flag which requests "kill this process if you're going to hibernate".

Then you could do the operations involving the secret in a dedicated subprocess.

This sounds usable to me and also promotes process-based isolation of application subcomponents.

I guess it should be theorically possible already for processes to do that. Systemd for instance is monitoring the suspend state.

mlock already allows you to do this so they likely did consider it

Reply on news.ycombinator.com