TEE
Last updated
Last updated
SEV (Secure Encrypted Virtualization) is a privacy computing model within AMD architecture. It aims to enhance isolation through cryptography by encrypting code and data, thereby protecting code from attacks by higher-privileged code.
Non-confidential computing systems operate on a ring-based model, where high-privileged code has full access to resources at its level and all lower privilege levels. In the SEV model, a hypervisor can control and run multiple virtual machines (VMs) simultaneously. When enabled, SEV hardware tags all code and data with a VM ASID, indicating which VM the data originates from or is intended for. This tag, stored alongside the data within the SoC, prevents the data from being accessed by anyone other than its owner. Inside the SoC, tags protect VM data, while outside the SoC, AES with 128-bit encryption safeguards the data. When data exits or enters the SoC, it is encrypted or decrypted based on keys associated with the tags. An example communication setup is shown in the diagram. In this example, SEV-enabled guests and the hypervisor communicate through shared memory, with both entities marked as shared. All other guest memory is encrypted using guest keys (inaccessible to the hypervisor).
Each VM and the hypervisor is associated with a unique tag, generating a corresponding encryption key. Due to tagging and memory encryption, data is restricted to the VM that uses that tag. If data is accessed by anyone else, including the hypervisor, they will only see its encrypted form. This establishes strong encryption-based isolation between VMs and the hypervisor.
Therefore, SEV technology is built on a threat model that assumes attackers may execute user-level privileged code on the target machine and potentially run malware at the higher-privileged hypervisor level. Attackers may also have physical access to the machine, including direct access to DRAM chips. In all these scenarios, SEV provides added assurance to help protect the VM's code and data from being compromised by attackers.
By utilizing hardware VM constructs, ZEROBASE prover nodes are built around the concept of a secure sandbox environment, where circuit programs can execute and remain isolated from other circuit programs on the system. These sandboxes enable encrypted isolation between Docker containers, housing different circuit programs, and the host system, thereby enhancing the security of the process from user input to proof generation and the release of user input.
ZEROBASE prover nodes implement private memory encryption at the container level, while shared memory on the host is encrypted using the hypervisor key. This feature allows VMs to designate selected pages for confidentiality-protected memory data, with other pages available for communication with the hypervisor. For security purposes, instruction pages and page table memory within ZEROBASE prover nodes are always private, ensuring protection for the virtual machine.
The security of SEV is highly dependent on the security of memory encryption keys, which cannot be accessed by the hypervisor itself. The SEV firmware, running inside the AMD-SP, provides a secure key management interface to achieve this. The hypervisor uses this interface to enable SEV for prover nodes and to carry out typical hypervisor activities such as launching, running, snapshotting, migrating, and debugging clients. This interface also facilitates the migration of client data to another prover node. During this operation, the memory content of the prover node remains encrypted throughout transmission. Once the remote platform is authenticated, the SEV firmware securely sends the memory encryption key for the prover node, allowing the remote platform to operate the client independently. This transmission mechanism enables ZEROBASE prover nodes to securely perform migration and replication with SEV enabled.
SEV alone cannot defend against denial-of-service (DOS) attacks targeting circuit programs. The defense mechanism for DOS involves issuing a single-use communication key to the user each time a request is initiated by the HUB.
