> 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 41 minutes 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.