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).

▲

bflesch 3 hours ago | parent | next [-]

Realistically as an Europeans we have the security threat of backdoored components from Epstein's colleagues at five eyes which are used for mass-surveillance of VMs at European hosters such as Hetzner. And every time you add a configuration option like memory encryption it makes their drive-by mass surveillance a tiny bit more difficult and hopefully easier to detect for the sysadmins at Hetzner.

IMO using the specialized CPU instructions (AES) is not clever because they'd obviously have backdoored that instruction to simply remember all keys that were used.

It's part of a defense-in-depth approach that Europe unfortunately needs as Europeans are considered as foreigners without any human rights by the five eyes community. America and their major tech leaders have made that abundantly clear to Europe, including the hitler salute as cherry on top.

I'm quite sad we have reached this situation, but if one is serious about security these things need to be discussed and if possible implemented.

▲

pbmonster 8 hours ago | parent | prev [-]

> 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?

▲

matja 7 hours ago | parent [-]

I can think of a few reasons:

There wasn't any such features for x86 when the patch was created, other than AES-NI.

Many hardware platforms that have TPM, have it connected via a low-bandwidth LPC bus which would have nowhere near enough bandwidth for demand decryption/encryption of memory pages.

Hardware vendors can apparently turn these security features off as they wish, even if the hardware supports and was shipped with it :)

▲

pbmonster 5 hours ago | parent [-]

> Many hardware platforms that have TPM, have it connected via a low-bandwidth LPC bus which would have nowhere near enough bandwidth for demand decryption/encryption of memory pages.

Ah, of course. I was more thinking along the lines of "CPU loads the key for decrypting RAM directly from the TMP into registers, and reloads it from there after waking from suspend or after a task switch has refilled those registers".

	▲	zorgmonkey an hour ago \| parent [-]
		I don't know exactly how long loading value from a TPM takes, but my gut says it would be much too long to do it on task switch. Almost certainly fine for waking up from suspend though. Also the problem that physical TPMs communicate with the CPU over plaintext and TPMs in general, including fTPMs, have had notable vulnerabilities.