There is a saying in security that it is difficult to secure a system if the attacker is able to tinker with hardware itself. On the server side, most of those issues have been put away by locking down said hardware in reasonably secured locations. But on the client side, those solutions are not possible.

Phones vs. PCs

Phones, as tightly integrated pieces of equipment with SoC and soldered components, were the first to benefit, by default, from storage encryption and integrated secure platforms. In an effort spearheaded by Apple, they have become mostly secure in the last 5 years. Instead, the more traditional x86 PC started to lag behind significantly. The modularity of the platform seems to make it difficult to close all doors and reach the same level of protection as a smartphone. So aside from the use of disk encryptions, nothing moved. The recent rants against TPMs requirements in Windows 11 are proof that those are not broadly available.

Specifically, with more and more people setting up some kind of disk encryption by default , the main target shifted from cold storage to runtime memory. Either BitLocker on Windows or Cryptsetup on Linux are part of the OS installation process now.

Getting the data and secrets from system memory is much easier. The premise is that if you get physical access to any random running system, you can:

• get the RAM sticks out
• put them in liquid nitrogen to freeze the bits in-place …then hook them up to a custom test bench that will dump the content, including all secret keys, giving you access to any linked cold storage.

AMD Zen Memory Encryption

That’s why when AMD announced that they would implement in all Zen products— Ryzen & EPYC —memory encryption in hardware, I was really excited. The encryption and decryption is performed by the memory controller on-the-fly, at no visible performance cost, using keys stored in the processor’s own secure enclave, on-chip.

With this enabled, someone willing to get access to in-memory information would need to freeze not only the stick, but the entire system, and extract the encryption keys from the secure enclave itself. I’m not sure about the level of effort it would require, or even if it is possible at all. But for sure, it would be more difficult than to put some RAM sticks in nitrogen and hook them to a PCB to get the data out!

The feature itself was announced in 2016 but took some time to get out and information is still sparse. But after a few years it seems to have gotten to a reasonable place.

Secure Memory Encryption (SME)

This is the main feature. It allows the host to encrypt most of the data in memory though the page table. SME seems to be supported in hardware by all Ryzen and EPYC systems, but the process of enabling SME itself is OS-dependent. For example the Linux kernel has support for SME but disabled it by default recently due to boot issues. And Windows does not seem to support it at all, hence the need for TSME.

Transparent SME (TSME)

Basically SME, but enabled by the BIOS/UEFI itself and OS independent. The option is part of the base code distributed by AMD to UEFI vendors, so it should be present on most (all?) boards.

The option is usually found under Advanced > AMD CBS. Turning it On will enable SME at the UEFI and report the status as enabled to the OS. This is the one you likely want to use, and not SME. Flip the switch, and you’ve just made the job of anyone who seeks to get your data (allegedly) more tedious and cumbersome.

Note: My own guess is that CBS stands for Common Board Settings, but I couldn’t find it spelled out anywhere.

Secure Encrypted Virtualization (SEV)

Secure Encrypted Virtualization (SEV) is an extension of SME that effectively enables a per-virtual machine SME. In other words, SEV [makes it possible to] run encrypted virtual machines in which the code and data of the VM are private to the VM and may only be decrypted within the VM itself. _Source: https://en.wikichip.org/wiki/x86/sme_

SEV was supposed to be available on Ryzen Pro hardware, but there have numerous reports including statements from AMD that this is not the case. The hardware itself supports it, but the baseboard controller (PSP) does not, rendering the feature useless on a non-EPYC platform.

But SEV is really meant for Cloud Services Providers, allowing them to argue to customers that their workload is secured from the insider point of view. Still, it is a bit constrained for now. For example, as the keys live in the PSP within the CPU itself, live-migration of the VMs—a feature commonly used during hypervisor patch and maintenance—is not allowed.

Hardware table summary

See this thread on reddit.