AMD’s Secure Encrypted Virtualization (SEV) is one of the key highlights of AMD’s Epyc processors. It basically offers protection to virtual machines in untrusted environments through memory and register encryption. (bfiweek) By leveraging a separate AMD Secure Processor (AMD-SP) to execute sensitive operations, it makes attacks on the primary x86 cores less effective. In contrast to Intel’s Software Guard Extensions (SGX), which focus on protecting parts of an application, SEV protects full VMs.
The runtime protection of VMs is achieved by transparently encrypting a VM’s memory. The remote attestation feature of SEV allows cloud customers to validate the correct deployment of the VM. Since its introduction in 2016, AMD has introduced two extensions to SEV that add additional protection features to SEV. While SEV-ES adds encryption for guest VM registers, SEV-SNP introduces, amongst others, software-based integrity protection and an enhanced Trusted
Computing Base (TCB) versioning feature for the Chip Endorsement Key (CEK).
The CEK cryptographically links the target platform to the AMD root of trust. Both the runtime protection and the remote attestation feature require the hypervisor to use an interface provided by a dedicated firmware running on the AMD-SP. The SEV firmware is responsible for managing the memory encryption keys of the VMs and implementing the remote attestation feature of SEV.
This paper introduces a new approach to attack SEV-protected virtual machines (VMs) by targeting the AMD-SP. We present a voltage glitching attack that allows an attacker to execute custom payloads on the AMD-SPs of all microarchitectures that support SEV currently on the market (Zen 1, Zen 2, and Zen 3). The presented methods allow us to deploy a custom SEV firmware on the AMD-SP, which enables an adversary to decrypt a VM’s memory. Furthermore, using our approach, we can extract endorsement keys of SEV-enabled CPUs, which allows us to fake attestation reports or to pose as a valid target for VM migration without requiring physical access to the target host. Moreover, we reverse-engineered the Versioned Chip Endorsement Key (VCEK) mechanism introduced with SEV Secure Nested Paging (SEV-SNP). The VCEK binds the endorsement keys to the firmware version of TCB components relevant for SEV. Building on the ability to extract the endorsement keys, we show how to derive valid VCEKs for arbitrary firmware versions. With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rouge administrators, on currently available CPUs.
Scenario 1: Debug Override. The SEV API provides debug features that allow the de- and encryption of a VM’s memory. A similar feature exists for SEV-SNP. Both SEV’s and SEV-SNP’s debug features are subject to a policy check enforced by the SEV firmware. Only if a guest owner explicitly enabled debugging during the initial deployment, the SEV firmware will allow the debug API commands. By altering the SEV firmware, an attacker could override this policy enforcement to allow the debug commands regardless of a guest owner’s policy. To that end, the attacker must replace the SEV firmware on the physical machine that hosts the target VM.
Alternatively, the attacker could first migrate the targeted VM to a previously prepared system. The attacker can then use the previously mentioned debug API calls to decrypt a VM’s memory regardless of the policy specified by the guest owner.
Scenario 2: Forge Attestation. In this second scenario, the attacker has access to the control interface of the hypervisor to initiate migrations of SEV-protected VMs. However, in contrast to the first scenario, the attacker does not need to alter the firmware of the targeted host. Instead, the attacker needs to extract the CPU-specific endorsement keys of the same CPU microarchitecture as the targeted host’s CPU. These endorsement keys play a central role in the remote attestation feature of the SEV technology. To decrypt a VM’s memory, the attacker could fake the attestation
report during deployment or migration to trick a VM into accepting a malicious MA. The MA is part of a VM’s TCB and has access to the Offline Encryption Key (OEK) of exported VMs. Using the OEK, a malicious MA can decrypt a VM’s memory. For pre-SEV-SNP systems, a similar attack has been proposed. Both presented example scenarios require the attacker to gain code execution on the AMD-SP.
