A Partition Is Not a Force Field: What NVIDIA MIG Does—and Does Not—Isolate
NVIDIA Multi-Instance GPU (MIG) is a way to divide one large data-center GPU into several smaller, concurrent execution environments. The important question is not simply whether MIG partitions resources—it clearly does—but whether every effect produced by those resources is partitioned as well. The evidence examined here supports a practical judgment: MIG provides meaningful physical separation, yet some memory-system effects can remain visible across instance boundaries. Understanding that distinction helps readers evaluate both the value and the limits of MIG-based isolation.
The bargain behind a partition
GPUs are expensive to buy and operate, and many workloads do not keep an entire accelerator busy. Sharing one GPU among unrelated jobs can improve utilization, but sharing also creates two problems. One workload may slow another by competing for hardware, and a malicious workload may learn something from the competition. A partitioning mechanism must therefore do more than divide a scheduling queue. It must allocate enough of the underlying machine that one tenant receives predictable capacity and has fewer ways to observe another.
This distinction is why a GPU partition is useful even before security enters the discussion. Whole-GPU time-sharing can make one job wait while another runs, and it makes performance depend on a scheduler's decisions. Spatial partitioning instead lets the workloads proceed in parallel with assigned portions of the machine. The design goal is not that every instance becomes a miniature copy of the full GPU. It is that each instance receives a bounded, understandable share of the resources that determine its ordinary work.
That goal also creates choices for an operator. A single large instance may suit a memory-hungry workload, while several smaller instances may improve utilization for lighter jobs. The maximum instance count is device-dependent: NVIDIA's A100 guide describes up to seven, while the paper notes that supported GPUs can differ. More instances can also mean less memory per instance, so the most densely partitioned configuration is not automatically the most realistic one. These are deployment trade-offs within the resource model; they do not answer whether the model isolates every observable effect.
MIG is NVIDIA's answer to that problem on supported data-center GPUs. NVIDIA's A100 documentation describes spatial partitioning into up to seven independent GPU instances. Each instance receives its own memory, cache, and streaming multiprocessors, and the guide presents memory isolation and physical resource allocation as core capabilities. In practical terms, a provider can place separate workloads on different instances and let them run at the same time rather than making them wait for one another on a whole-GPU scheduler.
The research paper examines the more detailed hardware boundary behind that user-facing description. In the tested design, an instance receives dedicated streaming multiprocessors, crossbar ports, L2-cache slices, memory controllers, and DRAM channels. Those assignments matter for both performance and security. If two instances have distinct compute and memory paths, ordinary contention should be reduced, and the predictable behavior of one workload should be less dependent on what another workload is doing.
That is the bargain: better utilization without giving up the expectation that each tenant has a meaningful hardware boundary. The bargain becomes especially important when the GPU is used to serve private inference, process sensitive images or graphs, or host a trusted execution environment. An isolation claim is not a decorative feature in those settings. It shapes what users believe they can safely co-locate.
Why the L2 cache is the fault line
To see why the cache matters, start with the shortest useful model of GPU memory. A GPU contains many streaming multiprocessors, or SMs, that execute groups of threads in parallel. Each SM has private low-level caches, while the L2 cache sits farther out in the hierarchy and is organized into slices shared by the GPU's compute units. Device memory provides much more capacity but generally has higher access latency. The cache hierarchy exists to make repeated data access faster.
A shared cache can also become a measuring instrument. In a conventional eviction-based attack, an observer fills cache locations with its own data, waits while a victim runs, and then checks whether those locations were displaced. The observer does not need to read the victim's data. It infers activity from changes in timing or from the loss of its own cache lines. Such attacks depend on the observer and victim reaching the same cache sets or otherwise contending for the same cache capacity.
MIG changes that arrangement. When two workloads run in different instances, their L2 slices are physically assigned to those instances rather than treated as one undifferentiated cache. The paper's experiments found that the tested user-level memory accesses did not create cross-instance L2 evictions, and most tested driver-level activities did not either. That result is meaningful: the familiar route in which one tenant fills a cache set and another tenant evicts it is not the route demonstrated by this work.
But “the cache is partitioned” can describe more than one guarantee. It may mean that cache capacity and cache lines are assigned separately. It may also be taken to mean that every operation involving the cache—an ordering request, a flush, a request counted by hardware, or a delay in a memory instruction—is confined to one instance. The first guarantee does not logically imply the second. A machine can keep data locations separate while still allowing a control or coordination effect to reach more broadly.
This is easiest to see by separating three questions that are often compressed into one word. Where can an instance place and retrieve its data? Which other workloads can force that data out? And which events can change the time taken by an operation, even if no data is displaced? MIG's physical L2 assignment is directly relevant to the first two questions. The paper investigates the third. A timing difference can matter because an observer only needs a repeatable change in its own operation; it does not need a shared address or a readable copy of the neighbor's data.
The difference also explains why a hardware counter can be informative without being a literal transcript of the victim's instructions. A counter may record an operation that the hardware associates with the kernel currently under observation, even when the event was caused by activity elsewhere. That kind of observation must be interpreted carefully, but it can still reveal that the boundary is not behaving as a completely closed system. The paper therefore moves from profiler evidence to a less privileged timing measurement rather than treating a counter label as the attack itself.
That is the distinction this research makes visible. It does not say that one MIG instance can freely address another instance's cache lines. It asks whether operations associated with the memory system can leave an observable trace beyond the partition.
The diagram captures the paper's central separation. Physical resources remain assigned to their instances, and the tested eviction path does not cross that assignment. A different path—an effect associated with memory ordering—can nevertheless influence what another instance measures. The security question is consequently about observability, not just ownership.
The question behind “isolated”
The distinction matters beyond ordinary multi-tenancy because second-generation MIG on Hopper GPUs is tied to a larger security ambition. The paper describes Hopper's design as intended to support NVIDIA's confidential-computing framework, in which a confidential virtual machine can receive a hardware-isolated trusted execution environment without occupying an entire GPU. NVIDIA's confidential-computing materials describe cache-side-channel mitigation as part of that story. A gap in the underlying isolation model therefore deserves closer attention than a small performance anomaly would.
There is an important qualification. At the time of the study, NVIDIA had not released the driver needed to test MIG combined with confidential computing, so the researchers could not evaluate that exact configuration. The paper tests MIG behavior on an H100 and reports related results on other MIG-capable GPUs; it does not prove how every later MIG-plus-CC deployment behaves. The right conclusion is neither “confidential computing is defeated” nor “the issue is irrelevant.” It is that the isolation foundation needs to be understood at the level of actual hardware effects and actual software support.
The USENIX paper, Behind Bars: A Side-Channel Attack on NVIDIA MIG Cache Partitioning Using Memory Barriers, frames that investigation precisely. Its authors found that memory barriers, or membars, generated in one MIG instance can have side effects that propagate across L2 partitions and affect the timing of certain load operations in another instance. They also found that ordinary GPU activities—most notably kernel launches in the tested Hopper design—can trigger such barriers indirectly. The result is a timing signal that can reveal patterns in a neighboring workload.
The finding is based on controlled experiments, not an assumption that the vendor's design must be wrong. The researchers first compared a detector's behavior with and without a stressor in another instance, then examined which kinds of requests changed and whether a timing measurement could observe the change without relying on a privileged profiler. That progression matters because it tests both existence and usability. A cross-instance event that cannot be detected by an ordinary tenant would have a different security meaning from one that can be turned into a stable signal.
This is a narrower and more consequential claim than “MIG does not isolate anything.” The paper does not demonstrate arbitrary memory disclosure, direct access to another tenant's cache lines, or the failure of every performance guarantee. It demonstrates that physical partitioning leaves an effect boundary that is not identical to the resource boundary. The later evidence asks how that effect arises, how reliably it can be measured, and what workload information it can expose.
That framing also determines how to read the results. A low-level signal may be real without being equally useful in every deployment. It can depend on GPU generation, driver behavior, workload shape, batching, background noise, and the observer's ability to measure timing. Conversely, a signal does not need to reveal raw data to matter. Model identity, input or output size, graph choice, or the phase of an inference can be sensitive metadata when workloads are shared among tenants.
The most useful mental model is therefore two-dimensional. First ask what MIG owns: compute units, cache slices, memory paths, and other physical capacity. Then ask what the system allows an instance to affect or observe: ordering, flushing, counters, timing, and the rhythm of work submitted to the GPU. The first question explains why MIG is valuable. The second explains why the protection claim requires empirical testing.
MIG remains a substantial engineering response to the cost and unpredictability of whole-GPU sharing. Its partitions can prevent the classic cache-eviction route and support concurrent workloads that would otherwise compete for one undivided machine. The evidence does not erase those benefits. It changes the precision of the security statement: a physically separated resource is not automatically a completely isolated source of microarchitectural behavior.
The next step is to look at the memory hierarchy and the L2 partition itself in enough detail to see where that distinction becomes testable. Once the physical boundary is clear, the unusual role of a memory barrier—and the reason it can become a sensor—comes into view.