SNPeek: Side-Channel Analysis for Privacy Applications on Confidential VMs

SNPeek: Side-Channel Analysis for Privacy Applications on Confidential VMs

Speakers: Ruiyi Zhang

Conference: NDSS Symposium 2026

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

Overview

Confidential Virtual Machines (CVMs) built on technologies like AMD SEV-SNP promise hardware-enforced isolation that keeps data encrypted even from the cloud provider and hypervisor. Organizations are increasingly deploying privacy-sensitive workloads inside CVMs as a cheaper alternative to cryptographic approaches like multi-party computation or fully homomorphic encryption. But this talk from Google and CISPA researchers demonstrates that side-channel attacks can systematically violate the privacy guarantees these applications rely on -- and the hardware vendors consider this out of scope.

SNPeek is a framework for automated side-channel analysis of privacy applications running on confidential VMs. It combines multiple side channels operating at different granularities -- page tables (4KB), cache (64 bytes), ciphertext (16 bytes), and performance counters -- to construct attacks that leak individual user data from privacy-preserving computations. The researchers demonstrate concrete privacy violations against real-world applications including private heavy hitters algorithms, user-defined functions for computing on private data, and private information retrieval systems commonly used in advertising and private inference.

Background

▶ Watch: Why confidential VMs exist and the 'holy grail' promise of privacy (0:00)

The promise of confidential computing is a "holy grail for privacy": encrypt your data, send it to tamper-proof hardware, perform computation, and get results back -- with guarantees that no one, including the cloud provider, can access the raw data. In reality, confidential VMs like those built on AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) achieve this through a compromise: rather than designing hardware from scratch, they layer encryption and access control onto existing virtualization infrastructure.

Under the CVM threat model, the hypervisor, BIOS, firmware on other devices, and kernel drivers are all considered potentially malicious. The hardware and firmware inside the CVM boundary encrypt memory at runtime and enforce access controls that prevent the host from reading or modifying guest data. Users can verify through remote attestation that the environment is a legitimate confidential VM before sending encrypted data.

However, CVMs share physical hardware with other workloads, and this creates side channels. The hypervisor retains control over the nested page table, the last level cache is shared across VMs, ciphertext can be read even if the underlying plaintext cannot, and performance counters provide telemetry about VM execution. Across AMD SEV-SNP, Intel TDX, and newer architectures, page table and cache attacks remain fundamentally unmitigated -- they are architectural features, not bugs that can be patched.

Hardware vendors explicitly state that side-channel attacks are outside their security scope, placing the burden on software developers to use constant-time coding practices and avoid secret-dependent memory accesses -- requirements that are extremely difficult to satisfy for general-purpose applications.

Key Findings

▶ Watch: Four side channels at different granularities: page table, cache, ciphertext,... (4:00)

The central finding is that combining Sybil-style input attacks with side-channel observations can violate the differential privacy guarantees of applications running inside confidential VMs, even when those applications correctly add noise to their outputs.

In the histogram computation example, an attacker who controls some inputs can construct specially crafted fake entries that create distinguishable memory access patterns depending on whether a specific victim user accessed a particular website. Even though the application adds Laplace noise to the output to provide differential privacy, the side-channel traces reveal the underlying access patterns before noise is applied.

The framework operates in two phases. In the offline phase, the attacker obtains the target binary (which must be published for attestation purposes) and performs static/dynamic analysis to build a model of how different inputs produce different side-channel traces. In the online phase, the attacker deploys the model against live victim data, using the side-channel traces to infer private information about individual users.

Critically, this attack does not rely on any vulnerability in the CVM architecture. Known vulnerabilities like CacheWarp and RMPV/RMPKF violations are assumed to be patched. The attack exploits the architectural reality that page table access patterns and cache behavior are observable by the hypervisor by design.

Technical Deep Dive

▶ Watch: Impact on real-world privacy applications: heavy hitters, PIR, private inference (8:00)

The framework models side channels at four granularity levels, each providing different resolution of information leakage:

Page table side channel (4KB granularity): The hypervisor controls the nested page table and can observe which 4KB pages within the guest VM are accessed. This leaks memory access patterns at page-level resolution and is fundamental to the x86 virtualization architecture.

Cache side channel (64-byte granularity): The last level cache is shared between VMs on the same physical hardware. Cache-based attacks can observe memory accesses at cache-line granularity, providing 64x finer resolution than page table attacks.

Ciphertext side channel (16-byte granularity): While the hypervisor cannot decrypt guest memory, AMD SEV-SNP does not prevent reading the ciphertext. Changes in ciphertext at 16-byte aligned boundaries can reveal when specific memory locations are written, providing the finest spatial granularity.

Performance counters: Hardware performance counters expose metrics like instruction counts and branch statistics, providing a different class of information about workload behavior.

The privacy violation is formalized as follows: for privacy applications like histogram computation, users contribute data that is aggregated with differential privacy noise before output. The attacker creates enough Sybil inputs to ensure that the presence or absence of a specific victim's data creates a measurably different side-channel trace. For example, if user "Sundar" visited "embarrassing.com," the hashmap access pattern during histogram computation differs from the case where that entry does not exist, and this difference is observable through page table or cache monitoring even though the output has differential privacy protection.

This represents a fundamental gap: differential privacy protects the output channel but not the computation channel. The side-channel leakage occurs during processing, before noise is added.

Demo / Proof of Concept

▶ Watch: Sybil inputs plus side channels break differential privacy guarantees (10:00)

The researchers demonstrated privacy violations against several real-world privacy application categories:

• Private heavy hitters algorithms used in advertising to compute aggregate statistics without revealing individual contributions
• User-defined functions for computing on private data
• Private information retrieval (PIR) systems used in private inference

In the histogram example, the attack successfully distinguishes which websites individual users accessed by constructing Sybil inputs that amplify the side-channel signal. The framework and associated code have been publicly released for the research community to evaluate and extend.

The offline-online attack model is practical because CVM attestation requires publishing the exact binary that runs inside the enclave, giving the attacker full access to the code for offline analysis and model building.

Defensive Implications

▶ Watch: Q&A: relationship with AMD/Intel and why side channels get no CVEs (14:00)

This research exposes a significant governance gap in the confidential computing ecosystem. The hardware vendors (AMD, Intel) explicitly disclaim responsibility for side-channel attacks, stating they are outside the threat model. Cloud providers are left to implement their own mitigations, and software developers are told to use constant-time coding practices that are impractical for complex privacy applications.

The speaker, working at Google Cloud, described the dynamic with hardware vendors as a "different work relationship" rather than traditional vulnerability disclosure. Because vendors do not classify side channels as bugs, there are no CVEs issued, no bounties paid, and no urgency to fix the underlying architectural issues. Progress happens through multi-year negotiation about future hardware design rather than patch cycles.

Potential mitigations discussed include:

• Core isolation (not sharing CPU cores between VMs) eliminates most cache side channels but does not address page table or ciphertext leakage
• Architectural-level resource isolation in future hardware
• Oblivious RAM (ORAM) techniques to make memory access patterns independent of data
• Sybil input mitigation at the application level
• Continuous evaluation of privacy applications against side-channel models

The most important takeaway for defenders is that deploying an application inside a confidential VM does not automatically provide the privacy guarantees your threat model assumes. The gap between the privacy guarantee of the CVM and the privacy guarantee your application actually achieves must be explicitly analyzed.

Key Takeaways

• Side-channel attacks on confidential VMs exploit architectural features, not bugs -- page table and cache side channels remain unmitigated across AMD SEV-SNP, Intel TDX, and current architectures
• Combining Sybil inputs with side-channel observations can violate differential privacy guarantees even when applications correctly add noise to outputs
• CVMs leak information at four granularities: page table (4KB), cache (64 bytes), ciphertext (16 bytes), and performance counters
• Hardware vendors consider side channels out of scope, creating a responsibility gap between hardware, cloud providers, and application developers
• Attestation requirements inadvertently help attackers by requiring publication of the exact binary, enabling offline side-channel analysis
• The SNPeek framework and code are publicly available for evaluating privacy applications

About the Speaker(s)

Ruiyi Zhang is a researcher at Google working on confidential computing security. He presented on behalf of lead author Ray Jang, a final-year PhD student who could not attend. The research was conducted in collaboration between Google and CISPA (Helmholtz Center for Information Security). The team has a direct working relationship with hardware vendors AMD and Intel on confidential computing security improvements, giving them unique insight into the gap between vendor threat models and real-world privacy requirements.