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).
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.
Interesting insight. Any reason why the key can't be kept exclusively in the secure enclave / trusted platform module / crypto coprocessor?
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 :)
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".