AMD SEV

AMD SEV provides transparent memory encryption for virtual machines. Each VM is assigned a unique encryption key, generated and managed by the secure AMD Secure Processor (ASP). This key is used by the on-die Memory Controller to automatically encrypt all data written to RAM and decrypt it upon reading, making the encryption process invisible to the guest OS and applications.

• Key Isolation: The hypervisor never has access to the VM's memory encryption keys.
• Hardware-Based: Encryption/decryption occurs in the memory controller, minimizing performance overhead.
• Protection Scope: Encrypts the entire VM state in memory, including CPU registers (with SEV-ES and SEV-SNP).

SEV-ES extends base SEV by adding protection for the CPU register state. When a VM is interrupted (e.g., for I/O), the hypervisor must save its register context. SEV-ES encrypts this register state before the hypervisor can access it, closing a significant attack vector.

• Register Protection: Encrypts guest register state (RAX, RBX, etc.) on a #VC (VMM Communication) exception.
• Hypervisor Blindness: The hypervisor handles an encrypted blob of register data, preventing it from reading or manipulating the VM's execution state.
• Minimal Guest Modifications: Requires paravirtualized drivers in the guest OS to handle the secure communication protocol.

SEV-SNP is the most advanced iteration, introducing strong integrity protections to prevent hypervisor-based attacks like data replay, memory re-mapping, and corruption. It adds hardware-enforced Reverse Map (RMP) tables and guest page validation.

• Memory Integrity: Guarantees that encrypted memory pages have not been altered, swapped, or replayed by a malicious hypervisor.
• Isolated Execution Environment: Protects against attestation replay attacks by cryptographically tying a VM's launch measurement to its current state.
• Foundation for Confidential VMs: SEV-SNP is the basis for Confidential VMs (CVMs) in major cloud platforms like Google Cloud Confidential Computing and Microsoft Azure Confidential VMs.

A critical feature for deploying SEV-protected workloads in untrusted environments (e.g., public cloud). Remote Attestation allows a remote party to cryptographically verify the integrity and security state of a VM running on SEV hardware.

• Proof of Launch: The verifier receives a signed report from the AMD Secure Processor (ASP) containing a measurement of the VM's initial state (firmware, bootloader, kernel).
• Trust Chain: This measurement is rooted in the hardware's fused-in certificate, establishing a chain of trust from the silicon to the launched software.
• Runtime Reporting: With SEV-SNP, attestation reports can also include runtime measurements, proving the VM is running with integrity protections active.

A primary security goal of AMD SEV is to dramatically shrink the Trusted Computing Base (TCB). The TCB is the set of software/hardware that must be trusted for the system to be secure.

• Traditional VM: TCB includes the entire hypervisor, host OS, and firmware.
• SEV-Protected VM: The TCB is reduced to the AMD Secure Processor (ASP) silicon and the guest VM's own software. The hypervisor is removed from the TCB.
• Security Benefit: This architecture mitigates risk from hypervisor vulnerabilities, compromised host administrators, and malicious co-tenants on the same physical server.

AMD SEV is designed for practical deployment. It requires minimal changes to the hypervisor and guest operating system, especially with later generations (SEV, SEV-ES).

• Hypervisor Role: The hypervisor retains its management functions (scheduling, resource allocation) but is blinded to VM memory and register content.
• Guest OS Support: Base SEV often requires no guest OS changes. SEV-ES and SEV-SNP require paravirtualized drivers (e.g., sev-guest driver in Linux) to handle secure communication with the ASP.
• Compatibility: Enables the protection of unmodified, legacy applications within an encrypted VM, a key advantage for enterprise lift-and-shift scenarios to confidential computing clouds.

A Trusted Execution Environment (TEE) is a secure, isolated area within a main processor. It guarantees the confidentiality and integrity of code and data loaded inside it. The TEE protects these assets from all other software on the platform, including a compromised operating system. AMD SEV creates a TEE at the virtual machine (VM) level, while technologies like Intel SGX create TEEs (enclaves) at the application level. Key properties include:

• Isolation: Hardware-enforced separation from the "rich" OS.
• Attestation: Ability to prove the TEE's integrity to a remote party.
• Sealed Storage: Secure, TEE-bound encryption of persistent data.

Intel Software Guard Extensions (SGX) is Intel's flagship TEE technology. It allows applications to create private memory regions called enclaves. Code and data inside an enclave are protected from processes running at higher privilege levels, including the OS and hypervisor. Unlike AMD SEV, which encrypts an entire VM's memory, SGX provides fine-grained isolation at the application or function level. This makes SGX suitable for protecting specific algorithms or data segments within a larger, untrusted application, a common pattern in privacy-preserving AI inference.

Remote Attestation is a critical cryptographic protocol that underpins trust in TEEs like those created by AMD SEV. It allows a remote verifier (e.g., a service provider or a client) to cryptographically verify that:

1. The software is running inside a genuine hardware TEE (not an emulator).
2. The TEE's contents (code and initial data) are in a known, trusted state.
3. The TEE's identity and properties are certified by the hardware manufacturer (e.g., AMD). This process establishes a root of trust from the silicon to the application, enabling secure deployment of AI agents that must prove their integrity before receiving sensitive tasks or data.

A Hardware Root of Trust is an immutable, always-on security engine embedded within a silicon chip. It serves as the foundational, trusted source for all security operations on the platform. For AMD SEV, this is implemented via the AMD Secure Processor (ASP), a dedicated security coprocessor. The ASP:

• Generates and protects the unique encryption keys for each VM.
• Performs cryptographic measurements during platform boot.
• Facilitates the remote attestation process. This hardware-based anchor ensures that the security guarantees of SEV cannot be subverted by software alone, as all critical operations originate in this protected silicon.