INTFAIL: Using Spurious #VC Interrupts to Break AMD SEV-SNP

INTFAIL: Using Spurious #VC Interrupts to Break AMD SEV-SNP

Speakers: Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, Shweta Shinde

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=dCaUoYaAq5U

Overview

This talk, "INTFAIL: Using Spurious #VC Interrupts to Break AMD SEV-SNP," delves into a critical vulnerability discovered in AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP), the latest and most robust generation of AMD's confidential computing processors. Presented by Supraja Sridhara and Andrin Bertschi, the research exposes how an untrusted cloud hypervisor can exploit a flaw in the #VC interrupt mechanism to compromise the confidentiality and execution integrity of an SEV-SNP protected virtual machine (VM). The core of the attack, dubbed INTFAIL, revolves around the hypervisor's ability to inject spurious VMM communication interrupts (#VC interrupts) and manipulate associated metadata, leading to the leakage or alteration of sensitive kernel-level state within the guest VM.

The significance of this work cannot be overstated. AMD SEV-SNP is designed to protect VMs from a malicious hypervisor, a fundamental threat model in cloud environments. By demonstrating that an untrusted hypervisor can still exert control and extract secrets, INTFAIL challenges the very assurances provided by confidential computing technologies. The researchers not only detail the theoretical underpinnings of their attack but also build powerful attack primitives and showcase their efficacy on VMs running both Linux and the experimental Oak operating system, ultimately achieving a root shell and other critical compromises. This research highlights the intricate challenges in securing complex hardware-software interactions within trusted execution environments.

Background

▶ Watch: Introduction to INTFAIL attack on AMD SEV-SNP (0:00)

To understand the INTFAIL attack, it's essential to first grasp the evolution of VM-hypervisor communication, particularly in the context of hardware-assisted virtualization and confidential computing. In traditional virtualized environments, a guest VM often requires assistance from the hypervisor to execute certain instructions, such as I/O operations or privileged system calls. This communication typically occurs through VM exits: when the VM executes an instruction requiring hypervisor support, the hardware triggers an exit to the hypervisor. The VM would set up necessary state, for instance, by placing a value in the Rax register, which the hypervisor could then directly access, read, process, and write back before resuming VM execution. This model inherently trusts the hypervisor, as it has full access to the VM's memory and CPU state.

The landscape shifts dramatically with AMD SEV-SNP. Designed for confidential computing, SEV-SNP aims to protect VMs from an untrusted hypervisor. This means that the hypervisor, while still managing the VM's resources, can no longer directly access or modify the VM's memory or CPU state. The VM's memory is encrypted, and its CPU state is locked down. This presents a challenge: how does the VM communicate with the hypervisor for necessary operations without exposing its internal state? AMD addresses this with a novel mechanism: the VMM Communication Interrupt (#VC interrupt).

Instead of a direct VM exit to the hypervisor, when an SEV-SNP VM executes an instruction requiring hypervisor support, the hardware triggers a #VC interrupt to the VM itself. This allows the VM's kernel to handle the request internally. Within the #VC interrupt handler, the VM can then decide what data to share with the hypervisor. This is achieved by copying specific data to a shared buffer—a region of memory accessible to both the VM and the hypervisor, but carefully controlled by the VM. To inform the #VC handler about the nature of the instruction that caused the interrupt, the hardware also sets an exit reason register. The handler reads this register, determines the type of operation (e.g., a memory-mapped I/O read, a VMM call), copies relevant data (like the value of Rax) to the shared buffer, and then exits to the hypervisor. The hypervisor can then read from the shared buffer, perform its operations, write results back to the shared buffer, and resume the VM. Upon resumption, the #VC handler copies the results from the shared buffer back into the VM's state, completing the operation. This elaborate dance ensures that the VM maintains control over what information is exposed, preserving its confidentiality and integrity, and crucially, allows existing applications to run without modification, provided the kernel has the necessary support.

However, a critical design flaw lies in the hypervisor's capabilities. While the #VC mechanism is intended for legitimate VM-hypervisor communication, the hypervisor retains the ability to arbitrarily inject #VC interrupts at any point during the VM's execution, even when the VM is not executing an instruction that requires hypervisor support. Furthermore, when injecting such a spurious interrupt, the hypervisor can control the value of the exit reason register. This combination—arbitrary injection and control over the exit reason—is the root cause of the INTFAIL vulnerability. By tricking the VM's #VC handler into believing a legitimate operation is occurring, the hypervisor can coerce the handler into copying internal VM state (e.g., secret values in Rax) to the shared buffer, compromising confidentiality, or even copying malicious values from the shared buffer back into the VM's state, compromising execution integrity.

Key Findings

▶ Watch: Understanding AMD SEV-SNP's VMM Communication Interrupt (VC) (2:20)

The central discovery of the INTFAIL research is the profound security implication of the hypervisor's ability to inject spurious #VC interrupts and dictate the exit reason register in AMD SEV-SNP environments. This capability, despite SEV-SNP's design to protect against an untrusted hypervisor, allows the hypervisor to bypass crucial security boundaries. The researchers found that by injecting these interrupts at opportune moments and setting specific exit reasons, the hypervisor can trigger handlers within the guest VM that inadvertently leak or modify its global state. This directly undermines the core tenets of confidential computing: the confidentiality of the VM's data and the execution integrity of its processes.

The talk highlights that there are a total of 16 possible exit reasons for a #VC interrupt. By carefully selecting these reasons, the researchers developed a suite of powerful and expressive attack primitives. These primitives are the building blocks for more complex exploits:

1. Read and Write to Rax: By injecting a #VC interrupt with the vmmcall exit reason, the hypervisor can trick the VM's handler into copying the current value of the Rax register to the shared buffer (for reading) or copying a hypervisor-supplied value from the shared buffer back into Rax (for writing). This primitive provides arbitrary read/write access to a critical general-purpose register, enabling direct manipulation of application and kernel flow.
2. Read and Write to Kernel Memory: Leveraging the mmio_read and mmio_write exit reasons, the researchers demonstrated the ability to read from and write to arbitrary locations within the VM's kernel memory. This is a significantly more powerful primitive, as it allows for direct manipulation of kernel data structures, code pointers, and other sensitive information. This capability is foundational for many privilege escalation and data exfiltration attacks.
3. Skip Instructions: A more subtle but equally crucial primitive allows the attacker to increment the instruction pointer (IP). This is particularly useful for bypassing certain checks or undesirable side effects within the #VC handler that might otherwise crash the VM or terminate the attack. By strategically skipping instructions, the attacker can navigate complex handler logic and maintain control over the execution flow.

These primitives, built upon the fundamental flaw of spurious #VC interrupt injection, form a robust toolkit for an untrusted hypervisor to fully compromise an AMD SEV-SNP guest. The researchers demonstrated the practical applicability of these findings by implementing and validating these primitives on real-world systems, achieving 100% accuracy in their arbitrary kernel memory write primitive and using it as a foundation for their case studies.

Technical Deep Dive

▶ Watch: The core vulnerability: Hypervisor arbitrarily injects VC interrupts (3:30)

The technical core of the INTFAIL attack lies in the intricate abuse of the #VC interrupt handler, particularly for achieving arbitrary kernel memory writes. The speakers detailed how they constructed this powerful primitive, which serves as a foundation for many of their advanced exploits.

Let's first consider the benign case of an mmio_read operation within an SEV-SNP VM.

1. An application within the VM executes an mmio_read instruction, for example, loading data from a memory-mapped I/O address (specified by the RD register) into a general-purpose register like RBX.
2. Since this is an MMIO operation requiring hypervisor interaction, the hardware triggers a #VC exception, indicating an mmio_read operation via the exit reason register.
3. The VM's kernel-level #VC Handler is invoked.
4. A simplified implementation of this handler typically calls a function, get_pointer, which is designed to retrieve a pointer to the destination operand of the mmio_read instruction (in this example, a pointer to the RBX register within the application context).
5. The #VC handler then exits to the hypervisor, indicating that it needs the MMIO read value.
6. The hypervisor supplies the requested MMIO value.
7. Upon resumption, the #VC handler takes this value and writes it to the dereferenced pointer obtained from get_pointer, thereby updating the application's RBX register. The mmio_read operation is successfully completed.

Now, to mount the arbitrary kernel memory write attack, the researchers exploit this flow with two key ingredients: hijacking a pointer and then dereferencing that controlled pointer with an attacker-supplied value.

1. Injecting the Spurious Interrupt: The attacker (hypervisor) injects a #VC exception, falsely indicating an mmio_read operation, even though the VM is not executing any such instruction.
2. Calling get_pointer: As in the benign case, the #VC handler is invoked and calls get_pointer to determine where the (fictitious) MMIO read result should be placed. According to x86 calling conventions, function return values are typically stored in the Rax register.
3. Hijacking the Pointer: This is the critical step. The attacker leverages their previously established Rax write primitive (using the vmmcall exit reason) to overwrite the return value of get_pointer, which is held in Rax. Instead of a pointer to an application register, the attacker overwrites Rax with a pointer to an arbitrary memory location within the SEV-SNP VM's kernel space that they wish to modify. This effectively hijacks the pointer that the #VC handler intends to use.
4. Recovering Corrupt State: The #VC handler often includes various checks to ensure the integrity of the operation. Since the attacker has injected a spurious interrupt and manipulated internal state, these checks might lead to a kernel crash. To prevent this, the attacker uses a series of their Rax write and skip instruction primitives. These are used to carefully manipulate other registers and the instruction pointer, bypassing the integrity checks and ensuring the handler continues execution without crashing. This step requires precise knowledge of the target kernel's #VC handler implementation.
5. Supplying the Write Value: The #VC handler, having successfully navigated the initial logic with the hijacked pointer, then exits to the hypervisor to receive the "MMIO read value."
6. Writing to Arbitrary Kernel Memory: The attacker, acting as the hypervisor, supplies the malicious value that they want to write. Upon resumption, the #VC handler writes this value to the now-controlled, dereferenced pointer (which points to the attacker's chosen kernel memory location). This completes the arbitrary 8-byte kernel memory write.

The researchers achieved this powerful primitive with high efficiency, requiring a total of 34 #VC interrupt injections to write 8 bytes of kernel memory, demonstrating 100% accuracy. This arbitrary kernel memory write primitive is incredibly versatile, allowing the hypervisor to alter critical kernel data structures, redirect execution flow, or inject malicious code, forming the bedrock for more sophisticated attacks like obtaining a root shell.

Demo / Proof of Concept

▶ Watch: Developing powerful attack primitives using different exit reasons (5:20)

The researchers provided compelling demonstrations of the INTFAIL attack's capabilities through three distinct case studies, showcasing the practical impact of their primitives on real-world SEV-SNP VMs running Linux.

1. Leaking Kernel TLS Session Keys: Using their read memory primitives, the attackers successfully extracted sensitive kernel TLS session keys. This attack required 288 #VC injections to locate and exfiltrate the keys. This demonstrates a direct compromise of the VM's confidentiality, allowing an untrusted hypervisor to decrypt secure communication originating from within the VM.
2. Disabling IP Firewall Rules: This case study demonstrated a compromise of the VM's execution integrity and network security. The researchers crafted a shellcode that, once injected, replaced the standard network filter function used by IP tables. The modified filter function was designed to always return true, effectively disabling all firewall rules and allowing any network packet to pass through the VM. This exploit required 238 #VC interrupts to inject and activate the malicious shellcode. This capability could be used by an attacker to bypass network segmentation, exfiltrate data, or launch further attacks from the compromised VM.
3. Obtaining a Root Shell: The most impactful demonstration involved achieving a root shell within the SEV-SNP VM, representing a complete compromise of the guest operating system. This advanced attack required over 2,800 #VC interrupt injections. The process was detailed in a video demonstration, showing logs from both the SEV-SNP VM (left side) and the hypervisor (right side).

The root shell attack unfolded in several stages:

• Defeating ASLR: During the VM's boot process, the attackers leveraged a series of their read, skip, and write primitives to defeat both physical and virtual kernel Address Space Layout Randomization (ASLR). This crucial step allowed them to determine the exact memory locations of kernel functions and data structures, which is necessary for precise code injection.
• Shellcode Injection: After ASLR was defeated and the VM had fully booted, the attackers injected a carefully crafted shellcode into kernel memory. This shellcode was designed to spawn a root shell.
• Triggering the Shellcode: The injected shellcode was placed on a code path that is triggered when the VM receives a network ping.
• Gaining Root Access: Upon sending a ping to the VM, the injected shellcode executed, and the attackers were able to open a reverse shell connection, granting them full root privileges within the SEV-SNP VM.

These case studies unequivocally prove the severity of the INTFAIL vulnerability, demonstrating that an untrusted hypervisor can achieve arbitrary code execution and full control over an AMD SEV-SNP guest, completely undermining the security guarantees of confidential computing.

Defensive Implications

▶ Watch: Deep dive: Inner workings of the kernel memory write primitive (6:40)

The discovery of the INTFAIL attack necessitates immediate and robust defensive measures to restore the security assurances of AMD SEV-SNP. The researchers detailed both a software hotfix provided by AMD and proposed hardware-based mitigations.

AMD's Hotfix (Mainline Kernel 6.9, CVE-2024-xxxx):

AMD, in response to the responsible disclosure, released a hotfix that has been merged into the mainline Linux kernel, specifically version 6.9, and is being tracked under an assigned CVE ID (though the specific CVE number was not stated in the transcript, it would be a critical detail in a full article). This hotfix attempts to prevent spurious #VC interrupt injection by introducing a simple check within the #VC handler.

• Mechanism: When a #VC interrupt is received, the patched kernel now compares the opcode of the instruction that would have caused a legitimate #VC interrupt with the exit reason supplied by the hypervisor. If these do not match (i.e., the VM was not actually executing an instruction corresponding to the hypervisor's given exit reason), the kernel determines the interrupt is spurious and immediately panics, crashing the VM.
• Limitations: While this prevents the direct exploitation demonstrated by INTFAIL, the researchers highlight its inherent limitations:
• Opcode-only Check: The patch only checks the instruction's opcode. It does not consider the operands of the instruction. This is a significant gap, as distinguishing between a regular memory move (MOV) and a memory-mapped I/O move (MMIO_MOV) might depend on the memory region accessed (the operand's address).
• Complexity of Full Patch: A truly robust software patch would need to perform more sophisticated checks, potentially involving page table walks to ensure that the operands are indeed within memory-mapped regions that would legitimately trigger an MMIO operation. Such a comprehensive software-only solution quickly becomes complex, difficult to maintain, and prone to corner cases, which is why the current solution is considered a "hotfix" rather than a complete architectural fix.

Advocacy for Hardware-Based Solutions:

Given the complexity and inherent limitations of software-only patches for such a fundamental hardware-software interaction, the researchers strongly advocate for hardware-based solutions. They note that AMD already has such a solution in the works, centered around VM Privilege Levels (VMPL).

• VMPL Concept: Similar to the traditional x86 rings (Ring 0 for kernel, Ring 3 for user applications), SEV-SNP introduces VMPLs, ranging from VMPL0 (most privileged) to VMPL3 (least privileged).
• Deployment Model: A proposed deployment model involves running a trusted bridge in VMPL0. This bridge acts as an intermediary, an interface between the untrusted hypervisor and the guest operating system (e.g., a Linux kernel running in VMPL1-3). The bridge's role is to selectively filter and route interrupts.
• New Interrupt Injection Modes: AMD introduces two new modes for interrupt injection: Alternate and Restricted modes. These modes, coupled with a new interrupt vector called the doorbell interrupt, are designed to mitigate #VC attacks.
• Mitigation Mechanism: With Alternate and Restricted modes enabled, the hypervisor is no longer able to directly inject interrupts into VMPL1-3 (where the Linux kernel would reside). Instead, it can only inject interrupts into VMPL0, targeting the trusted bridge. The bridge, being trusted, can then decide whether to route the interrupt to the Linux kernel in VMPL1-3, effectively filtering out spurious injections. This prevents the hypervisor from directly manipulating the guest kernel's #VC handler logic.
• Current Status: As of the talk, there is no software support for these VMPL-based modes merged upstream into the Linux kernel, preventing the researchers from testing their efficacy against the INTFAIL attack.

The INTFAIL attack is also contextualized as part of a broader class of "In-a-Box" attacks, which exploit malicious notifications to break trusted execution environments (TEEs). The researchers mention their prior work, Heckler, which used different interrupt vectors to break both Intel TDX and SEV-SNP, further emphasizing the systemic nature of these vulnerabilities in TEE designs. The availability of their proof-of-concept exploits at aoex.lookup.i underscores their commitment to transparency and enabling further research.

Key Takeaways

• Fundamental Vulnerability: AMD SEV-SNP's VMM Communication Interrupt (#VC interrupt) mechanism is vulnerable to spurious injection by an untrusted hypervisor.
• Hypervisor Control: The untrusted hypervisor can arbitrarily inject #VC interrupts and control the associated exit reason register, tricking the guest VM's kernel into mishandling its state.
• Powerful Primitives: This vulnerability allows the creation of potent attack primitives, including arbitrary read/write access to the Rax register, arbitrary 8-byte kernel memory read/write, and instruction skipping.
• Comprehensive Compromise: These primitives enable severe attacks such as leaking kernel TLS session keys (288 #VC injections), disabling IP firewall rules (238 #VC injections), and achieving a full root shell within the SEV-SNP VM (over 2,800 #VC injections).
• Incomplete Software Patch: AMD released a hotfix in Linux kernel 6.9 (CVE-2024-xxxx) that attempts to mitigate the attack by checking the instruction opcode against the exit reason, but this solution is incomplete due to its inability to check operands or perform page table walks.
• Hardware Mitigation Needed: A more robust, hardware-based solution, such as AMD's proposed VMPL (VM Privilege Levels) with Alternate and Restricted interrupt injection modes, is necessary for a complete defense, but currently lacks upstream software support.
• Broader Attack Class: INTFAIL is part of a new class of "In-a-Box" attacks that exploit notification mechanisms to compromise trusted execution environments, highlighting a systemic challenge in TEE security.

About the Speaker(s)

The presentation was given by Supraja Sridhara and Andrin Bertschi, who are part of a research team that also includes Benedict Schlüter and Shweta Shinde. Based on the technical depth and academic conference (IEEE S&P) where this work was presented, they are likely security researchers, possibly affiliated with an academic institution, specializing in the field of confidential computing, trusted execution environments, and hypervisor security. Their work focuses on identifying and exploiting vulnerabilities in cutting-edge hardware security features like AMD SEV-SNP and Intel TDX, contributing significantly to the understanding of their security models and the development of robust defenses.