Inside AMD SEV: How memory encryption works today(and where it is lacking)

Source: Dev.to

AMD SEV vs Intel SGX

AMD SEV (Secure Encrypted Virtualization) can be thought of as building a fortress around an entire house: the operating system, all applications, and data are encrypted and protected from the outside world (the cloud provider or hypervisor). If a thief manages to get inside the house—e.g., through a malware infection in the guest OS—they can see everything inside.

Intel SGX (Software Guard Extensions), on the other hand, is like placing a steel vault inside a room of the house. Even if the house has no walls and thieves (a compromised OS or hypervisor) are roaming freely, they cannot access the vault. Only the specific items placed in the vault are protected.

Adoption by Cloud Providers

The major cloud players—Azure, Google Cloud, and NVIDIA—are heavily promoting AMD SEV. The reasons are practical:

• Model weights are expensive to risk exposing.
• Training data is often subject to strict regulations.

When AMD SEV is paired with NVIDIA GPUs, it provides a hardware‑level guarantee that even the computer owner cannot inspect what the machine is processing. This is especially valuable for scenarios such as training a fraud‑detection model in a bank, where a “clean room” is required that prevents any visibility into the computation.

Limitations of AMD SEV

While the encryption layer of AMD SEV is robust, it does not hide all aspects of a workload’s behavior. Observers can still infer information from:

• The timing of each operation.
• Which memory addresses are accessed.
• The overall shape of the computation.

For AI inference, the shape of the computation can leak details about the model or its inputs. This side‑channel leakage is a problem that has not yet been fully addressed in the confidential computing space. In practice, an attacker who can monitor the “design and decoration” of the encrypted environment may glean a surprisingly accurate picture of what is happening inside.