PAGE404: Breaking GPU Isolation Through Hardware-assisted Page Migration

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.