Overview

This chapter tests whether NVIDIA MIG’s timing signal transfers beyond LLMs and across GPU generations. Reported demonstrations classified five known graphs at 98.4% macro F1, traffic-image categories at 83% F1, and 20 same-length MoE prompts at 99% F1; these are selected classification tasks, not arbitrary secret recovery. Kernel-launch leakage was shown on H100 and reported on H200, while tested A30 and A100 systems retained direct timing effects without the same launch-based demonstration. Batching and noise limit attribution, while the exact MIG-plus-CC configuration and Blackwell behavior were not independently tested.

Learning outcomes

The timing mechanism transferred to graph, object-count, and expert-routing distinctions when application structure made traces repeatable.
Reported F1 scores—98.4% for five graphs, 83% for traffic categories, and 99% for MoE prompts—measure selected tasks, not arbitrary secret recovery.
H100/H200 kernel-launch results did not transfer unchanged to tested A30/A100 systems, where direct timing effects remained but the same launch path was absent.

Keywords

MIGWorkloadsHopperAmpereBatchingNoise

The Boundary Conditions: Other Workloads, GPU Generations, and Limits

The LLM results show that a cross-instance timing signal can expose workload metadata, but NVIDIA MIG should not be judged from one favorable application alone. This chapter tests the scope of the finding in two directions: across workloads whose secrets are represented by graphs, images, or routing decisions, and across GPU generations and deployment conditions. The aim is to separate the mechanism that transfers from the measurements that remain conditional, so that a reported classifier score is read as evidence about a selected task rather than as a promise of universal information recovery.

The same signal, different secrets

The common feature in the additional demonstrations is not language. It is a workload whose internal structure changes the number, order, or duration of GPU kernels in a repeatable way. The receiver still measures a timing trace produced through the cross-instance membar effect. What changes is the hidden application property that shapes the trace. In one case it is graph structure, in another it is the number of detected objects, and in a third it is how tokens are routed among experts.

Graph processing makes the relationship especially clear. In a workload such as breadth-first search, the size and structure of the input graph affect how much work must be done and how many CUDA kernels are launched. Two graphs processed by the same algorithm can therefore produce different sequences of kernel activity. The paper demonstrates this with five social-network graphs from the Stanford Network Analysis Project. A classifier trained on traces from those candidates achieved a macro F1 score of 98.4%, with recall of 98.5% and precision of 98.4%.

The result does not mean that a graph can be reconstructed from timing alone. It means that, among the five candidates and under the tested execution conditions, their traces were sufficiently distinct for the classifier to identify which candidate was being processed. A deployment with an unknown graph, a different implementation, or more background work could produce a less separable set of traces. The security significance is still concrete: identifying which known social or operational dataset is being processed can reveal information even when the graph's vertices and edges never cross the MIG boundary.

The object-detection demonstration uses a different source of variation. In region-based detection models such as Fast R-CNN, the number and spatial distribution of objects can change the amount of later-stage computation. More objects can lead to different region-proposal work and therefore different kernel counts, orderings, or execution times. The paper compares traces from images containing five objects with traces from images containing more than 30 objects and reports visibly different patterns. A classifier then separated light-traffic and heavy-traffic images from a traffic-camera dataset with an F1 score of 83%.

That lower score is not evidence that the mechanism stopped working. It reflects a more difficult classification problem and a different application mapping.

Published by DeepMox

FAQ

Can the NVIDIA MIG timing method classify non-LLM workloads?

Yes, the reported demonstrations classified selected graph candidates, traffic-image categories, and mixture-of-experts routing patterns from timing traces. They depended on repeatable application structure and did not reconstruct graph data or images.

What do the reported F1 scores actually establish?

The reported F1 scores establish performance on defined classification problems, not arbitrary secret recovery. Each result depended on a candidate set, training examples, an observation window, and a receiver configuration.

How does batching change workload attribution?

Batching can make per-request attribution unreliable even when timing traces still show coarse information. With multiple prompts decoding at once, an observer may see several phase boundaries or output lengths without reliably assigning each one to a prompt.

Previous11 minNVIDIA MIG Membar+Load for LLM Inference

Next10 minNVIDIA MIG Defenses Against Timing Leakage

NVIDIA MIG Side Channels: Workloads and GPU Generations

The Boundary Conditions: Other Workloads, GPU Generations, and Limits

The same signal, different secrets

FAQ