CounterSEVeillance: Performance-Counter Attacks on AMD SEV-SNP

CounterSEVeillance: Performance-Counter Attacks on AMD SEV-SNP

Speakers: Stefan Gast

Conference: NDSS Symposium

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

Overview

In the rapidly evolving landscape of confidential computing, Confidential Virtual Machines (CVMs) represent a significant stride towards protecting data in use. This talk, "CounterSEVeillance: Performance-Counter Attacks on AMD SEV-SNP," presented by Stefan Gast at the NDSS Symposium, uncovers a critical vulnerability in AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) technology. The research demonstrates how malicious hypervisors can leverage Hardware Performance Counters (HPCs) in conjunction with a novel single-stepping technique to extract sensitive information, including cryptographic keys, from CVMs.

The core of the issue lies in the fundamental difference between traditional Trusted Execution Environments (TEEs) and CVMs. While TEEs often rely on specialized enclaves and constant-time programming for security, CVMs aim to run general-purpose operating systems and applications, which are rarely designed with such stringent side-channel resistance in mind. Gast's work highlights that even with robust memory encryption and integrity protection offered by SEV-SNP, the leakage of microarchitectural state via HPCs can compromise the confidentiality of secrets processed within the VM, challenging the very premise of general-purpose confidential computing.

This research is particularly significant because it reveals a powerful new class of attacks that bypass the architectural protections of AMD SEV-SNP. By showing how an untrusted hypervisor can precisely observe guest execution at an instruction level and correlate it with performance counter increments, the talk underscores the need for a re-evaluation of threat models and mitigation strategies for CVMs. The implications extend beyond theoretical concerns, demonstrating practical key recovery attacks against widely used cryptographic algorithms like RSA and TOTP, as well as post-quantum schemes, demanding immediate attention from hardware vendors, software developers, and security practitioners.

Background

▶ Watch: Introduction: TEEs, Confidential VMs, and side channels (0:00)

The concept of Trusted Execution Environments (TEEs) emerged to protect sensitive computations from potentially malicious software layers, such as operating systems or hypervisors. Traditional TEEs, like Intel SGX, typically involve specialized enclaves running highly constrained code, often requiring constant-time programming to prevent information leakage through side channels. These side channels exploit variations in execution time, cache access patterns, or power consumption that depend on secret data.

Confidential Virtual Machines (CVMs), such as those powered by AMD SEV-SNP, represent a different paradigm. Instead of isolated enclaves, CVMs aim to protect entire virtual machines, including their guest operating systems and general-purpose applications, from an untrusted hypervisor. While AMD SEV-SNP provides strong architectural protections like memory encryption and integrity verification, the challenge for CVMs is that the vast majority of existing software running within them was never designed with the strict side-channel resistance requirements of TEEs in mind. This means general-purpose code frequently contains secret-dependent branches or operations whose execution paths vary based on sensitive data.

The foundation of the "CounterSEVeillance" attack relies on Hardware Performance Counters (HPCs). These are special-purpose registers within the CPU that count specific hardware events, such as instructions executed, branches taken, cache misses, or even the duration of specific operations like divisions. The crucial observation made by the researchers is that these HPCs continue to increment even when an AMD SEV-SNP protected virtual machine is executing. This incrementation, observable by the hypervisor, provides a window into the guest's microarchitectural activity.

A key enabler for this attack is prior work that demonstrated the feasibility of single-stepping AMD SEV-protected virtual machines. While architectural single-stepping (e.g., via debug registers) is prevented in SEV-SNP, a clever trick involving a hardware timer allows the hypervisor to effectively execute the guest VM instruction by instruction. By setting a precise hardware timer to expire just after a single guest instruction executes, the hypervisor can regain control, query the HPCs, and then resume the guest for the next instruction. This combination of granular control over guest execution and observable microarchitectural events forms the bedrock of the CounterSEVeillance attacks.

Key Findings

▶ Watch: Attack Methodology: Single-stepping with performance counters (3:45)

The primary finding of the "CounterSEVeillance" research is the critical vulnerability of AMD SEV-SNP to performance-counter side-channel attacks orchestrated by a malicious hypervisor. Despite AMD SEV-SNP's robust memory encryption and integrity protections, the researchers discovered that Hardware Performance Counters (HPCs) remain accessible and increment in response to guest VM activity. This leakage of microarchitectural information allows an untrusted hypervisor to infer secret-dependent execution paths within the confidential VM.

The core contribution is the demonstration of a novel attack methodology that combines two key elements:

1. Precise Single-Stepping: Leveraging a hardware timer trick, the hypervisor can force the AMD SEV-SNP guest to execute instruction by instruction, giving the attacker fine-grained control over the observation window.
2. Granular HPC Observation: After each single instruction, the hypervisor queries the HPCs to observe changes in event counts, such as instructions executed, branches executed, branches taken, and division operation durations.

By correlating these HPC changes with the single-stepped execution, the attackers can recover the control flow of the guest VM. Specifically, they can determine if a conditional branch was executed and, crucially, whether that branch was taken or not taken. This outcome directly leaks information about the condition being evaluated, which, in cryptographic algorithms, often depends on secret data.

The research successfully demonstrates the practical impact of this vulnerability through several high-profile attacks:

• Full RSA Private Key Recovery: The attack can fully reconstruct a private RSA key by observing the secret-dependent branch in the square-and-multiply exponentiation algorithm. This was achieved with 100% success rate and no bit errors within approximately 7 minutes.
• TOTP Token Recovery: By targeting memcmp operations used in Time-based One-Time Password (TOTP) validation, the attack can determine the correct digits of a TOTP token one by one, recovering the token before it expires, again with 100% success.
• TOTP Secret Key Extraction: Even more critically, the underlying Base32 decoder used to process the TOTP secret key can be attacked by counting loop iterations, allowing the full secret key to be stolen.
• Post-Quantum Cryptography Attacks: The methodology extends to divide-and-surrender style attacks on the HQC (Hamming Quasi-Cyclic) post-quantum crypto scheme, demonstrating that even next-generation cryptographic primitives are susceptible to this class of side channels due to secret-dependent division operations.

These findings collectively highlight that the assumption of confidentiality for general-purpose applications running in AMD SEV-SNP CVMs is flawed when a malicious hypervisor has access to HPCs and can perform precise single-stepping. The research underscores the urgent need for architectural mitigations to prevent hypervisors from gaining such fine-grained insights into guest execution.

Technical Deep Dive

▶ Watch: RSA Private Key Recovery: Square and multiply attack (6:15)

The "CounterSEVeillance" attack hinges on a sophisticated combination of microarchitectural observation and precise control over guest execution within an AMD SEV-SNP VM. The core methodology can be broken down into three main stages: single-stepping, performance counter query, and page fault tracking.

Single-Stepping the Confidential VM

Architectural single-stepping, typically achieved using debug registers, is explicitly prevented by AMD SEV-SNP to protect guest confidentiality. However, the researchers employed a clever hardware timer-based trick. The untrusted hypervisor starts a hardware timer and then resumes the confidential VM. The timer is configured to expire after a very short, precisely calculated duration—just enough time for the guest VM to execute a single instruction. When the timer expires, an interrupt is triggered, causing the hypervisor to regain control from the guest VM. At this point, the hypervisor knows that exactly one instruction (or a very small, known number of instructions) has been executed within the guest since the last resume. This allows the hypervisor to effectively single-step the guest VM, observing its state after each instruction.

Performance Counter Query

After each single-step, when the hypervisor regains control, it queries the Hardware Performance Counters (HPCs). The critical observation is that these counters increment based on guest execution even within an SEV-SNP protected environment. The specific HPCs leveraged in this research include:

• Instructions Retired: Total number of instructions executed.
• Branches Executed: Total number of branch instructions encountered.
• Branches Taken: Total number of branch instructions where the jump was actually performed.
• Division Operations: The duration or count of division instructions.

By comparing the HPC values before and after each single instruction execution, the hypervisor can precisely determine which of these events occurred during that single instruction's execution.

Page Fault Tracking for Targeted Attacks

Single-stepping an entire virtual machine is prohibitively slow. To make the attack practical and target specific cryptographic routines, the researchers utilized page fault tracking. This technique allows the hypervisor to monitor memory accesses within the guest VM. The process involves:

1. Identifying Target Code: The attacker first identifies the memory pages containing the cryptographic function they wish to attack (the "target pages"). They also identify a "start page," typically the page containing the caller of the target function.
2. Setting Breakpoints: The hypervisor marks these pages as non-present, triggering a page fault whenever the guest attempts to access them.
3. Initiating Tracking: When a page fault occurs on the "start page," the hypervisor knows the guest is about to enter the function of interest. At this point, it enables single-stepping and HPC observation.
4. Monitoring Execution: The hypervisor continues single-stepping and monitoring HPCs as long as the guest executes instructions within the "target pages."
5. Terminating Tracking: Once the guest's instruction pointer leaves the "target pages," indicating the function has returned, the hypervisor disables single-stepping and HPC observation, resuming normal VM execution until the next page fault on a start page.

This targeted approach significantly reduces the overhead, allowing the attack to focus only on relevant code snippets.

Control Flow Recovery and Secret Leakage

The combination of single-stepping and HPC observation enables the recovery of the guest's control flow. Specifically, by analyzing the "Branches Executed" and "Branches Taken" counters:

• If "Branches Executed" is zero, the instruction was not a branch.
• If "Branches Executed" is one and "Branches Taken" is zero, the instruction was a conditional branch, and the condition evaluated to false (the branch was not taken).
• If "Branches Executed" is one and "Branches Taken" is one, the instruction was a conditional branch, and the condition evaluated to true (the branch was taken).

This precise knowledge of branch outcomes directly leaks information about the secret data being processed by the guest VM.

Attack Examples:

1. RSA Private Key Recovery (Square-and-Multiply):

• The square-and-multiply algorithm for modular exponentiation, a core part of RSA decryption, iterates through each bit of the secret exponent.
• Inside the loop, there's a conditional branch: if the current secret bit is 0, only a "square" operation is performed; if it's 1, both a "square" and a "multiply" operation are performed.
• The attack observes the outcome of this specific branch. If the branch is not taken, the secret bit is 0; if it is taken, the secret bit is 1. (The talk mentions compiler inversion, meaning the observed outcome might be inverted, but the correlation holds).
• By observing the branch outcome for each iteration, the entire RSA private key can be reconstructed. The researchers achieved 100% success in 7 minutes, with no bit errors.

1. TOTP Token Validation (Memory Compare):

• Time-based One-Time Passwords (TOTP) are often validated by comparing a user-provided token with a server-generated one using a function like memcmp.
• memcmp typically compares bytes sequentially and returns early if a mismatch is found. This creates a secret-dependent branch: the loop continues as long as bytes match.
• By observing how many times the memcmp loop iterates before a branch indicates a mismatch, the attacker can guess the TOTP digit by digit.
• The traces show distinct patterns for two correct digits versus three correct digits, allowing precise inference. This attack achieved 100% success, recovering tokens before expiration.

1. TOTP Secret Key Extraction (Base32 Decoder):

• The underlying Base32 decoder used to process the shared secret key from which TOTP tokens are derived often involves a loop that iterates over each encoded byte and compares it against a lookup table.
• The number of loop iterations or specific branch behaviors within this decoder can reveal the length or specific values of the encoded secret.
• While the loop in the COOTP library (and others like it) was "very tight," making single-stepping less reliable, the attack still demonstrated the feasibility of extracting the secret key by counting pattern occurrences in the trace.

1. HQC (Post-Quantum Crypto) Attacks (Division Operations):

• The research also extended to post-quantum cryptographic schemes, specifically HQC (Hamming Quasi-Cyclic).
• Certain modular arithmetic operations within HQC compile down to division instructions, which are often secret-dependent.
• By monitoring HPCs related to division operations (e.g., their duration or count), the attacker can mount divide-and-surrender style attacks, similar to those previously seen on other cryptographic implementations. This demonstrates the broad applicability of the HPC side channel beyond just branch prediction.

The technical depth of this research highlights that even fundamental CPU operations, when observed through HPCs and combined with precise execution control, can undermine the security guarantees of advanced confidential computing platforms.

Demo / Proof of Concept

▶ Watch: TOTP Token Recovery: Memory compare side channel (8:00)

The talk effectively demonstrated the practical feasibility of the CounterSEVeillance attacks through several compelling proof-of-concept examples, presenting clear traces and success rates for each. While no live "demo" in the traditional sense (e.g., real-time hacking on stage) was shown, the researchers presented detailed results derived from their implemented attack framework.

For the RSA private key recovery, the demo involved generating execution traces for the square-and-multiply exponentiation algorithm. Gast showed specific trace visualizations where the branch related to the secret bit evaluation behaved differently based on whether the bit was 0 or 1. For a secret bit of 0, the trace indicated the branch was "not taken." Conversely, for a secret bit of 1, the trace clearly showed the branch being "taken` at a specific step (e.g., step 20). This precise observation allowed for the full recovery of the RSA private key within 7 minutes, achieving a 100% success rate with no bit errors, unequivocally proving the attack's efficacy.

Similarly, the TOTP token validation attack was demonstrated by showing how the memcmp function's execution trace varied based on the number of correct digits in a guessed TOTP token. The presentation highlighted distinct patterns in the branch outcomes and loop iterations when comparing two correct digits versus three correct digits. This allowed the attacker to deduce the TOTP token digit by digit, significantly reducing the brute-force search space. This attack also boasted a 100% success rate, enabling the recovery of a TOTP token before its expiration.

Beyond token validation, the researchers also demonstrated the ability to steal the underlying TOTP secret key by targeting the Base32 decoder implementation. While the success rate for this particular attack was slightly less than 100% due to the "very tight" nature of the decoder's loop, which sometimes impacted the reliability of single-stepping, the principle of inferring secret information through pattern counting in the execution trace was clearly shown.

Finally, the talk touched upon divide-and-surrender style attacks on HQC, a post-quantum cryptographic scheme. This proof-of-concept focused on leveraging the observation of secret-dependent division instructions through HPCs, illustrating that the attack vector is not limited to conditional branches but extends to other microarchitectural events tied to sensitive computations. These demonstrations collectively underscored the broad applicability and devastating potential of the CounterSEVeillance methodology against a range of cryptographic implementations within AMD SEV-SNP CVMs.

Defensive Implications

▶ Watch: HQC Post-Quantum Crypto Attack: Divide and surrender (11:00)

The "CounterSEVeillance" research presents profound defensive implications for the entire ecosystem of confidential computing, particularly for AMD SEV-SNP and similar CVM technologies. The core message for defenders is clear: relying solely on memory encryption and integrity protection at the hardware level is insufficient when a malicious hypervisor can observe microarchitectural side channels.

1. Rethink the Threat Model for CVMs: The assumption that general-purpose operating systems and applications can run securely in a CVM without modification needs re-evaluation. Unlike traditional TEEs that often require specialized, hardened code, CVMs aim for broader compatibility. This talk demonstrates that existing, unhardened general-purpose code is inherently vulnerable to microarchitectural attacks when exposed to a powerful attacker like a malicious hypervisor. Defenders must recognize that the "general-purpose" nature of CVMs is a double-edged sword, expanding the attack surface significantly.

1. Hardware-Level Mitigations are Crucial: The most effective long-term defense against this class of attack must come from the hardware vendor, AMD.

• Disable Hypervisor Access to Guest HPCs: The most direct mitigation would be for AMD SEV-SNP to prevent the hypervisor from reading guest-specific HPCs. If the hypervisor cannot observe these counters, the attack becomes impossible.
• Granularity Reduction: If complete disabling is not feasible, reducing the granularity or precision of HPCs for guest VMs could make fine-grained single-stepping attacks impractical.
• Randomization/Noise Injection: Introducing noise or randomization into HPC readings for guest VMs could obscure the precise, secret-dependent variations.

1. Software Hardening (Constant-Time Programming): While difficult to enforce broadly for general-purpose software, the research reiterates the importance of constant-time programming for any security-critical code running within a CVM. This includes cryptographic libraries, authentication mechanisms, and any code handling sensitive data.

• Patching Vulnerable Libraries: As seen with mbedTLS (which changed its code in version 3.6+ to remove the vulnerable if branch), software developers must audit and update their libraries to remove secret-dependent branches and operations. This requires a dedicated effort to identify and mitigate such patterns across a vast codebase.
• Compiler and Toolchain Support: Tools and compilers could be developed to help identify or even enforce constant-time execution, though this remains a complex research area.

1. Application-Level Awareness: Developers of applications handling sensitive data within CVMs must be aware of these side-channel risks. Even if the underlying OS and hypervisor are trusted, the application's own code can leak secrets if not carefully written. This extends to post-quantum cryptographic implementations, which also need to be designed with side-channel resistance in mind from the outset.

1. Monitoring and Detection: While preventing the attack at the source is ideal, defenders could also explore monitoring techniques within the guest VM to detect unusual execution patterns or attempts at single-stepping, though this is challenging given the hypervisor's privileged position.

In summary, the "CounterSEVeillance" talk serves as a stark reminder that security in confidential computing is a multi-layered problem. Hardware, operating systems, and applications all play a role, and a vulnerability in one layer can undermine the protections of others. For AMD SEV-SNP, the immediate action points are clear: address the HPC leakage at the hardware level and encourage widespread adoption of side-channel resistant coding practices for critical software components.

Key Takeaways

• AMD SEV-SNP is vulnerable to hypervisor-based performance counter side-channel attacks: Despite strong architectural protections, a malicious hypervisor can leverage Hardware Performance Counters (HPCs) to observe guest execution.
• Combination of single-stepping and HPCs is a powerful attack vector: By precisely single-stepping the guest VM using a hardware timer trick and querying HPCs after each instruction, the hypervisor can reconstruct control flow and infer secret data.
• General-purpose code is inherently vulnerable in CVMs: Most existing software is not designed for constant-time execution, making secret-dependent branches and operations easily exploitable within confidential VMs.
• Practical attacks demonstrated against critical cryptographic schemes: The research successfully extracted RSA private keys (100% success in 7 min), TOTP tokens (100% success before expiration), TOTP secret keys, and attacked post-quantum HQC, showcasing real-world impact.
• Hardware-level mitigations are urgently needed: AMD must address the hypervisor's ability to access guest HPCs or reduce their granularity to prevent such precise side-channel leakage.
• Software hardening (constant-time programming) remains crucial: Security-critical libraries and applications running in CVMs must adopt constant-time coding practices, and existing vulnerable implementations (like mbedTLS prior to 3.6) need to be patched.

About the Speaker(s)

Stefan Gast presented the talk "CounterSEVeillance: Performance-Counter Attacks on AMD SEV-SNP" at the NDSS Symposium. The research was a joint effort, with co-authors Hannes Wstein, Robin Leando Shredder, and Daniel Guz also contributing to the work. Stefan Gast, in his presentation, demonstrated expertise in the area of trusted execution environments and side-channel analysis, particularly focusing on the security implications for confidential virtual machines. His work highlights a significant vulnerability in AMD's SEV-SNP technology, underscoring the ongoing challenges in securing general-purpose computing within confidential environments.