logoalt Hacker News

matjatoday at 9:50 AM1 replyview on HN

There was a patch called Tresor that did this, but I don't think it was updated for a long time.

You have to store the encryption key in CPU registers and ensure it's not saved to RAM during task switching or power suspend operations. Tresor used x86-specific debug registers for it, but you could potentially use unused SIMD registers if you masked-off the CPUID bits for them and disabled them for access by user-space.

But securing against attacks from a hostile hypervisor or a server provider needs more than just memory encryption, because they can intercept any part of the boot process and control the hardware/firmware that can lie to your kernel.

To counter that you'd need something like AMD SEV(ES/SNP) with measured boot and remote attestation to switch the only thing you trust to the CPU manufacturer (best you can do IMO).


Replies

pbmonstertoday at 10:04 AM

> You have to store the encryption key in CPU registers and ensure it's not saved to RAM during task switching or power suspend operations.

Interesting insight. Any reason why the key can't be kept exclusively in the secure enclave / trusted platform module / crypto coprocessor?

show 1 reply