PAGE404: Breaking GPU Isolation Through Hardware-assisted Page Migration
Listen
Radio episode about this paper
Transcript
Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.
Nadia: I'm Nadia.
Elias: And I'm Elias, here with Priya.
Nadia: Today's paper: "PAGE404: Breaking GPU Isolation Through Hardware-assisted Page Migration".
Elias: The gist The access-counter hardware structure is shared across Multi-Instance GPU (MIG) boundaries, violating MIG’s security guarantees, and we further identify a migration-delay leakage arising from the driver’s interrupt-handling pipeline.
Nadia: First, who's behind it and why it matters.
Title and authors: Nadia: We’ve talked about the title and authors of "PAGE404: Breaking GPU Isolation Through Hardware-assisted Page Migration." Basically, it tells us right away that they are targeting a specific mechanism—hardware-assisted page migration—and the goal is breaking isolation.
Elias: They are authored by Ravan Nazaraliyev, Yicheng Zhang, and Nael Abu-Ghazaleh. Their focus is on finding vulnerabilities in NVIDIA’s Grace Hopper superchip architecture concerning how it manages data movement between the CPU and GPU memory.
Priya: It sets the stage for a very specific kind of attack research; they aren't looking at general security issues, but they are zeroing in on this unique hardware feature to see if it introduces new leakage vectors.
Nadia: They are showing that this page migration support, while designed to improve performance by promoting frequently accessed pages to the GPU DRAM, actually creates pathways for side-channel and covert channel attacks when tenants share the same underlying hardware structures.
Elias: The paper sets up the premise that there’s a shared structure within the access counter hardware across different tenants, which is where they find their first vulnerability.
Priya: This means we need to look at how these counters are organized and what kind of information they expose about what other processes are accessing.
Nadia: It suggests that the way this hardware is implemented, with its set-associative structure similar to caches, makes it susceptible to contention attacks where one process can try to evict another process’s counters.
Elias: And they also found a second vulnerability related to the driver itself; specifically, how calls made by one process can affect the response time of migration events for another.
Priya: So, if you are running on a system like this, you have to consider that your memory access patterns aren't just affecting your own performance; they might be influencing what’s happening in other partitions.
Nadia: Exactly. The paper frames this as breaking the isolation guarantees expected from MIG partitioning by targeting a GPU-wide shared resource.
Elias: And they are proving that this shared resource is a weak point, showing how it can be exploited across those different instances.
Priya: This gives us concrete data on how these channels work, moving beyond just theoretical concerns to actual measurable metrics like bits per second.
The paper's summary: Nadia: Now let’s look at the summary of "PAGE404: Breaking GPU Isolation Through Hardware-assisted Page Migration." It boils down to them investigating the security of NVIDIA’s page migration support against side-channel and covert channel attacks.
Elias: They specifically examine how the system uses access counters to dynamically promote pages from host CPU memory into GPU DRAM to boost memory locality for generative AI and HPC workloads.
Priya: The mechanism they study is driven by these per-region hardware counters that track GPU accesses to system memory pages, notifying the driver when a configurable threshold is reached, triggering migration.
Nadia: And the paper reverse-engineers both the access-counter subsystem and the UVM driver’s interrupt-handling mechanism to understand exactly how they operate under the hood.
Elias: The summary highlights that they found two previously unexplored side-channel vulnerabilities stemming from this analysis: one related to shared counter structure and another related to migration contention on the shared driver.
Priya: The key finding is that both channels target a GPU-wide shared resource, which means the isolation boundaries between MIG partitions are being breached by exploiting this common element.
Nadia: This investigation leads them to demonstrate several specific attacks, including an eviction-based covert channel achieving eight thousand five hundred bps at a one point five percent error rate.
Elias: And they also show the migration-delay leakage channel, which they characterize as being able to distinguish between CUDA and LLM workloads with around or above ninety percent accuracy.
Priya: It’s important to stress that these findings aren't just theoretical; they are measurable attacks that can be run against the GH200 platform.
The paper's improvements: Nadia: The paper discusses several improvements they suggest for securing this architecture, focusing on closing the security gap exposed by their findings.
Elias: One major suggestion is to partition the access counters into groups dedicated to each MIG partition instead of sharing them across all tenants. They argue that this directly addresses the finding that the hardware access counter pool is finite and shared across MIG instances.
Priya: That moves away from a shared pool toward dedicated pools, which would fundamentally restore the isolation guarantees expected in a multi-tenant GPU environment by preventing cross-partition interference through resource contention on those counters.
Nadia: They also point to the driver code as another vector for leakage, suggesting that better handling of migration events and contention within the driver pipeline could help mitigate the second channel they identified.
Elias: They are also looking at how different Polybench kernels can be identified by observing specific access patterns related to system-allocated memory usage, which is a way to fingerprint workloads.
Priya: That level of fine-grained access metering sounds useful because it allows us to infer more precise details about the victim’s memory usage without needing full data access.
Conclusion: Nadia: So, as we wrap up with "PAGE404: Breaking GPU Isolation Through Hardware-assisted Page Migration," the main implication is that current MIG isolation guarantees are not sufficient against these hardware-level side-channel attacks on the GH200.
Elias: The root of the vulnerability is that shared counter hardware structure, and the shared access to driver code allows for contention and leakage through observable delays.
Priya: It means we need to prioritize architectural changes, like partitioning those counters into dedicated groups for each MIG partition, to truly secure these multi-tenant GPU environments.
Nadia: They’ve shown that different Polybench kernels can be identified by the leakage if they are using system-allocated memory, which is a useful diagnostic tool for security researchers.
Elias: The migration delay leakage also enables a covert channel of eight thousand one hundred bps at a four percent error rate, and it lets us estimate the processed token length during LLM inference with high accuracy.
Priya: So what we’re left with is that we need to design systems where isolation holds up even when these shared components are present, or else these attacks become a realistic threat.
Nadia: We've seen how this hardware mechanism can create a channel for communication and inference about other tenants' activity, which is something we need to take seriously in exploitation research.
Elias: The work on "PAGE404: Breaking GPU Isolation Through Hardware-assisted Page Migration" shows that the isolation guarantees we rely on in a multi-tenant GPU setup might not hold up when this hardware is involved.
University of California, Riverside · George Mason University
cs.CR, cs.AR
Submitted: 2026-10-14
Updated: 2026-10-18
Code: https://github.com/NVIDIA/cuda-samples
License: http://creativecommons.org/licenses/by/4.0/
Importance score: 79/100
The gist: The gist The access-counter hardware structure is shared across Multi-Instance GPU (MIG) boundaries, violating MIG’s security guarantees, and we further identify a migration-delay leakage arising
Key concepts
- Hardware-assisted Page Migration
- This feature automatically moves data pages between the host CPU memory and the GPU's local DRAM based on access patterns tracked by hardware counters. The goal is to improve memory locality for high-performance computing tasks without requiring manual software intervention.
- Access Counters
- These are hardware registers that track how many times a specific system memory page is accessed by the GPU. In this architecture, these counters are shared across different GPU instances within the same physical hardware, creating a shared resource that can be exploited for communication.
- Multi-Instance GPU (MIG)
- MIG is a feature designed to provide strong isolation between multiple virtual GPUs running on a single physical NVIDIA GPU. The paper investigates how the shared access counter structure violates these intended security guarantees by allowing cross-tenant information leakage.
Summary
The gist The access-counter hardware structure is shared across Multi-Instance GPU (MIG) boundaries, violating MIG’s security guarantees, and we further identify a migration-delay leakage arising from the driver’s interrupt-handling pipeline.
How it works
The paper investigates the security of NVIDIA’s Grace Hopper (GH200) superchip's hardware-assisted page migration support against side-channel and covert channel attacks targeting its page migration support By eliminating the conventional PCIe bottleneck that has long constrained CPU–GPU data movement, this design establishes a unified memory domain that scales to the capacities demanded by generative AI and high-performance computing (HPC) workloads The architecture also introduces hardware-assisted page migration support: driven by access counters, the system dynamically promotes frequently accessed pages from host CPU memory to the GPU DRAM to improve memory locality This policy is implemented through access counters: per-region hardware counters that track GPU accesses to system memory pages and notify the UVM driver once a configurable threshold is reached The driver then migrates the corresponding pages from host DRAM to GPU-local memory, optimizing memory locality without requiring programmer intervention
The analysis reverse-engineered the access-counter subsystem and the UVM driver’s interrupt-handling mechanism to characterize their structure and behavior The first channel stems from the shared structure of the access-counter hardware across tenants, where notifications are triggered deterministically once a migration threshold is reached This shared structure can be exploited using contention (e.g., evicting other processes’ counters) for covert communication across tenants Similarly, the leakage through these shared counters can be measured (observed through the presence or absence of migration) to identify victim accesses to the same counter set
Key Vulnerabilities and Channels
The paper identifies two previously unexplored side-channel vulnerabilities stemming from this analysis The first channel stems from the shared structure of the access-counter hardware across tenants, where notifications are triggered deterministically once a migration threshold is reached The second channel exploits migration contention on the shared driver, where calls to the driver (e.g., to launch a new kernel) can be detected since they affect the response latency to migration events Crucially, both channels target a GPU-wide shared resource, which makes them exploitable across Multi-Instance GPU (MIG) partitions
Building on these findings, the authors demonstrate several covert and side-channel attacks The eviction-based covert channel achieves 8500 bps at a 1.5% error rate, rising to 15500 bps at roughly 5% error with two eviction sets The migration-delay leakage enables a covert channel of 8100 bps at a 4% error rate and, across several side-channel attacks, distinguishes CUDA, and LLM workloads with around or above 90% accuracy, estimating the prompt length processed during LLM inference with high accuracy
Attack Methodology and Results
The authors implement two types of attacks for both covert and side channel: (1) a channel based on counter eviction sets (Fig. 12 A), and (2) a channel based on variation in the migration delay ∆ induced by a co-located process (Fig. 12 B) The critical parameter governing attack effectiveness is the sampling rate, where parallel accesses are more suitable for capturing more details
The access counter set-based covert channel relies on sender and receiver communicating through these access counter sets, with the sender accessing its own eviction sets to transmit a ‘1’ and staying idle to transmit a ‘0’ The receiver attempts to trigger a migration by completing N accesses in two steps, then waits for a duration D to allow the sender to signal, and finally completes the remaining δ accesses This channel achieves 8500 bps at a 1.5% error rate, rising to 15500 bps at roughly 5% error with two eviction sets
The migration-delay variation covert channel leverages the fact that the hardware-assisted page migration delay can be varied based on the concurrent GPU context This channel achieves approximately 8,100 bps with a 4% error rate It relies purely on software-level contention, which makes it unstable across runs primarily because the contention level is difficult to control
Side Channel Fingerprinting
The paper demonstrates several cross-tenant side-channel attacks between processes located on different MIG partitions that exploits two distinct leakage vectors to spy on different workloads The eviction-based side channel distinguishes among 10 CUDA workloads with 94% accuracy when they use systemallocated memory Furthermore, the migration delay leakage enables a co-located process to infer information about its CPU workload by observing how heavy CPU memory activity can stall the GPU’s migration work
The authors also show that even when a tenant runs no GPU workload at all, a spy can still infer side-channel information about that tenant’s CPU workloads because page migration requires the writer-prioritized mmap lock to read the process’s memory map This is because concurrent CPU memory operations (for example, munmap calls) can delay the migration’s read request
Conclusion and Future Work
The results expose a security gap in hardware-managed heterogeneous memory systems and call into question the isolation guarantees of current MIG-enabled multi-tenant GPU deployments The authors conclude that PAGE404 attains a high attack success rate and underscores the need for more secure architectures in multitenant environments The root of the vulnerability is the shared counter hardware structure, and the shared access to the driver code enables contention and causes leakage through observable delays One approach for mitigation is to carry the MIG philosophy to ensure isolation even through these shared components in software and hardware This requires partitioning the counters into groups of counters dedicated to each MIG partition rather than sharing the counters across them The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory
The paper presents a range of proof-of-concept covert- and side-channel attacks on the GH200 platform These results show that PAGE404 attains a high attack success rate and underscore the need for more secure architectures in multitenant environments The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access The authors also show that different Polybench kernels can be identified by the leakage if they are using systemallocated memory The final observation is that distinct pages within the same 2 MB range aggregate accesses to a single shared counter, and migration is performed on the specific 64 KB region targeted by the most recent access <ref:7
Improvements for AI systems
-
Improved isolation for multi-tenant GPU environments by partitioning hardware resources to close shared counter pools across MIG partitions, directly addressing Observation 3:
The hardware access counter pool is finite and is shared across Multi-Instance GPU (MIG) instances, violating the isolation guarantees expected of MIG partitioning.
-
Enhanced workload identification for co-located processes by implementing a defense against migration delay leakage:
This covert channel leverages the fact that the hardware-assisted page migration delay can be varied based on the concurrent GPU context,
which allows distinguishing betweenCPU, CUDA, and LLM workloads with around or above 90% accuracy
(Conclusion). -
Accurate inference of Large Language Model (LLM) input/output prompt length by leveraging migration delay variation: The system can estimate the processed token length with a
mean absolute error of 4.6 tokens on average
by analyzing theMigration Delay leakage enables a covert channel of 8100 bps at a 4% error rate
(Conclusion). -
Fine-grained access metering for kernel fingerprinting: By exploiting the architectural granularity mismatch, the system can transform a binary access detection channel into a quantitative side channel that can
infer the victim’s precise access count within a 5% margin of error
(Section 4.4.8).
Abstract
NVIDIA's Grace Hopper (GH200) superchip represents a new generation of heterogeneous computing, tightly integrating a 72-core Arm-based CPU with a Hopper GPU on a single module via a high-bandwidth, cache-coherent interconnect. By eliminating the conventional PCIe bottleneck for CPU-GPU data movement, this design establishes a unified memory domain that scales to the capacities demanded by generative AI and high-performance computing (HPC) workloads. The architecture also introduces hardware-assisted page migration: driven by access counters, the system dynamically promotes frequently accessed pages from host CPU memory to GPU DRAM to improve memory locality. We study the security of this emerging architecture against new side- and covert-channel attacks targeting its page migration support. We analyze counter-driven migration across both the hardware mechanisms and the UVM driver's interrupt-handling pipeline, and identify two side-channel vulnerabilities: one rooted in the shared structure of access counters, and the other in the driver's response to migration interrupts. We further show that both channels are exploitable across Multi-Instance GPU (MIG) partitions, a feature intended to provide strong, hardware-enforced isolation between co-located tenants. Using proof-of-concept attacks, we build covert channels that reach roughly 8,500 bits per second through eviction-based signaling and 8,100 bits per second through migration-delay-based signaling across MIG instances. The interrupt-based channel also fingerprints inference workloads across distinct large language models (LLMs) and CPU SPEC2017 benchmarks, and estimates the prompt length processed during LLM inference with high accuracy. These results expose a security gap in hardware-managed heterogeneous memory systems and call into question the isolation guarantees of current MIG-enabled multi-tenant GPU deployments.
Sources
- InstInfer: In-Storage Attention Offloading for Cost-Effective Long-Context LLM Inference
- NVBleed: Covert and Side-Channel Attacks on NVIDIA Multi-GPU Interconnect
- UVMBench: A Comprehensive Benchmark Suite for Researching Unified Virtual Memory in GPUs
- LLaMA: Open and Efficient Foundation Language Models
- Qwen3 Technical Report
- RouterBench: A Benchmark for Multi-LLM Routing System
- Gemma 3 Technical Report
Related papers
- SoK: AI-Augmented Binary Reversing
- Relaxed Sender Anonymity for CBDC Interbank Settlement: A Zero-Knowledge Approach on Permissioned EVM
- Calibration-Family Overfit: Why Trusted Sabotage Monitors Don't Transfer Across Lineages
- Efficient Fuzzy PSI under One-Sided Assumptions
- Sealing the Audit-Runtime Gap for LLM Skills
- Token Composition: A Graph Based on EVM Logs