MIG Isolation Violations: What Cross-Partition Access Looks Like and Why Nothing Detects It Today
For executives
NVIDIA's Multi-Instance GPU (MIG) technology partitions a single GPU into multiple isolated instances with separate compute resources, memory, and caches. MIG isolation is stronger than time-slicing and stronger than vGPU software isolation — it is hardware-enforced. But hardware isolation and perfect isolation are not the same thing. Research has documented that MIG logical partitioning may have flaws, that certain shared resources can create cross-partition information channels, and that without monitoring of the container-to-MIG mapping, cross-partition access is currently undetectable by any standard security tool.
What MIG isolation provides
MIG partitions a supported GPU (A100, H100, and later) into GPU Instances. Each GPU Instance has a separate: compute partition (a fixed set of streaming multiprocessors), L2 cache partition, memory partition (a fixed HBM address range), and memory controller partition.
This hardware partitioning means code in one MIG instance cannot directly access the compute resources, L2 cache, or HBM memory of another MIG instance. This is a stronger isolation guarantee than software-based separation.
Where MIG isolation does not fully extend
Hardware isolation covers the primary compute and memory resources. Several aspects of the GPU are shared across MIG instances:
The NVDEC/NVENC video encode/decode engines (on supported hardware) may not be fully MIG-partitioned. PCIe bandwidth to the host is shared across MIG instances. The GPU's global scheduler makes scheduling decisions that affect all MIG instances. NVLink connectivity may create shared fabric resources.
Research on GPU confidential computing has noted that isolation mechanisms like MIG may have flaws and that logical partitioning alone does not guarantee security without careful validation.
The container-to-MIG mapping gap
Even if MIG hardware isolation is perfect, without visibility into which container maps to which MIG slice, a security operations team cannot verify that the container-to-MIG assignment is correct or that it has not been tampered with.
A compromised container runtime or a misconfigured MIG assignment could place a malicious container on a MIG instance adjacent to a legitimate workload's instance, positioning it to exploit any shared resources between instances. Without monitoring of the container-to-MIG mapping, that placement is invisible.
Why cross-partition access is undetectable
Standard runtime security tools monitor container processes, system calls, and network activity. MIG partition assignments are managed by the GPU driver and the GPU Operator — not by container-level tooling. GPU-specific telemetry that tracks MIG slice assignments per container and monitors which GPU memory regions each container's CUDA context accesses provides the necessary visibility.