WeSee: Using Malicious #VC Interrupts to Break AMD SEV-SNP

TL;DR

WeSee demonstrates that a malicious hypervisor can inject external #VC interrupts into AMD SEV-SNP VMs to subvert the VM’s trusted state. By analyzing the VC handler and chaining/nesting #VCs, the attacker derives primitives to skip instructions, read/write $rax$, read kernel memory, write kernel memory, and inject arbitrary code, ultimately leaking keys, disabling firewall rules, or spawning a root shell. The work provides three end-to-end case studies and discusses mitigations spanning software hardening and hardware defenses, including protecting exit_reason and restricting external #VC injections. The findings have broad implications for SEV-SNP deployments and highlight the need for hardware-assisted mitigations to preserve VM confidentiality and integrity in cloud environments.

Abstract

AMD SEV-SNP offers VM-level trusted execution environments (TEEs) to protect the confidentiality and integrity for sensitive cloud workloads from untrusted hypervisor controlled by the cloud provider. AMD introduced a new exception, #VC, to facilitate the communication between the VM and the untrusted hypervisor. We present WeSee attack, where the hypervisor injects malicious #VC into a victim VM's CPU to compromise the security guarantees of AMD SEV-SNP. Specifically, WeSee injects interrupt number 29, which delivers a #VC exception to the VM who then executes the corresponding handler that performs data and register copies between the VM and the hypervisor. WeSee shows that using well-crafted #VC injections, the attacker can induce arbitrary behavior in the VM. Our case-studies demonstrate that WeSee can leak sensitive VM information (kTLS keys for NGINX), corrupt kernel data (firewall rules), and inject arbitrary code (launch a root shell from the kernel space).

Figures (8)

• Figure 1: (a) Benign execution of #VC in SEV VM. 1. application sets up rax and does vmmcall 2. CPU intercepts the instruction and raises #VC with exit_reason set 3. VC handler copies values (rax) into GHCB and exits to hypervisor 4. Hypervisor returns back to the VC handler which copies values (rax) from GHCB 5. Return to application that caused #VC. (b) Attack execution with WeSee.
• Figure 2: (a) VC chaining. VC1 changes rax, VC2 changes rcx. (b) 1-level VC nesting.
• Figure 3: Timing the #VC injection. 1. Hypervisor observes page fault sequence [Page$_{c}$, Page$_{r}$, Page$_{c}$] and injects #VC when Line 4 returns. 2. This triggers the execution of the VC handler, which when done returns back to the application on Page$_{c}$
• Figure 4: Psuedo-code of VC handler with effects.
• Figure 5: Read memory primitive. (a) Handler description for #VC caused by instruction mov [rdi], rbx. (b) Pseudo-code of MMIO write handling. (c) Attack steps. (d) Attack dataflow. (e) Memory used for attack.