What Operators Can Do: Reducing Signal Without Pretending It Is Gone
The evidence about NVIDIA MIG does not lead to one universal switch called “secure.” It leads to a choice among defenses that act on different parts of the side-channel path. This chapter compares those choices for application authors, GPU operators, and platform teams: adding noise to the timing signal, reducing the kernel-launch structure that gives the signal meaning, accepting co-running noise as only a partial obstacle, and moving to a hardware or vendor configuration with stronger isolation. The practical goal is to reduce residual observability while keeping the cost and uncertainty of each option visible.
Four levers, four different targets
A mitigation is easier to judge when its target is explicit. The demonstrated path has several stages: a victim activity generates or correlates with a membar; the memory system leaves a timing effect across MIG instances; a receiver measures its own strong-load latency; and an attacker maps the resulting trace to a workload property. A defense can disrupt the signal, make the victim's launch rhythm less distinctive, add uncertainty to the receiver's measurements, or change the underlying hardware behavior. Those are not interchangeable outcomes.
The first option is to add barrier activity deliberately. The paper suggests that a victim with access to more than one MIG instance could run a secondary workload that randomly issues MEMBAR.GPU or MEMBAR.SYS while the main application runs elsewhere. An application could also insert broad-scope barriers directly. The purpose is obfuscation: if the victim produces additional, unpredictable membar events, a receiver has more difficulty deciding which timing changes correspond to the sensitive workload.
This defense targets the timing signal itself. It does not restore the physical boundary by making the L2 partitions more separate; it makes the observation less informative by adding extra events. That distinction matters when the attacker can average many samples. Random activity may reduce the signal-to-noise ratio without eliminating the underlying relationship, especially if the added pattern is too regular or too sparse. The paper also warns that barriers can impose high performance overhead. They are ordering operations with system consequences, not free random bits.
The cost is not limited to cycles. An application must know where an added barrier is safe, how it interacts with its own correctness requirements, and whether it can obtain a second instance for a noise-generating workload. A barrier inserted at the wrong point could change synchronization behavior rather than merely disguise it. The supplied evidence supports barrier obfuscation as a practical direction, but not as a tested, complete mitigation standard. It should be treated as a measured hardening layer whose residual signal must be checked on the actual workload.
The second option is to reduce the frequency of short kernel launches. The demonstrated application side channels work because ordinary GPU applications repeatedly submit kernels, and the intervals between those submissions carry information about the work being performed. Merging work into fewer, longer-running kernels can make the launch trace less detailed.