Overview

Membar+Load turns cross-instance membar activity into a binary timing channel: a receiver measures its own parallel LD.STRONG.GPU latency rather than reading another instance’s memory. On the tested H100, capacity peaked at 1.57 Kb/s; co-running workloads reduced it to reported ranges of about 0.77–1.30 kbps. In controlled LLM experiments, traces supported candidate-model, phase, and approximate length inference, but batch size, noise, prior examples, and model choice limited the claims.

Learning outcomes

Membar+Load uses receiver-side LD.STRONG.GPU latency as a binary signal, without shared memory or direct data access.
On the tested H100, channel capacity peaked at 1.57 Kb/s; reported co-running workloads reduced it without eliminating it.
LLM traces supported candidate-model, phase, and length inference in selected settings, not recovery of prompts, weights, or output text.

Keywords

MIGMembar+LoadLLMInferenceTimingMetadata

From Timing Signal to Leakage: Membar+Load and LLM Inference

NVIDIA MIG's cross-instance timing effect becomes a security concern when it is turned into a repeatable observation. This chapter examines Membar+Load, the channel built from that effect, and its main application case: inferring properties of large language model inference from kernel-launch patterns. The important judgment is not that an observer reads a neighboring model's data. It is that a workload's timing rhythm can disclose metadata—model identity, execution phase, or approximate input and output sizes—when the rhythm is stable enough and the deployment conditions match the tested threat model.

A one-bit channel without shared memory

A covert channel is a way for two parties to communicate through a resource or effect that was not intended to carry their message. In the paper's setup, a sender and receiver run in different MIG instances on the same NVIDIA GPU. They do not need shared data or the same CPU hardware, and neither needs privileged access to the performance profiler. They do need access to processor timing information available through a user-level GPU clock such as CLOCK, along with an agreed protocol that tells both sides when a transmission begins and how long each interval lasts.

Membar+Load uses the cross-instance effect as a binary signal. During one transmission interval, the sender repeatedly issues memory barriers to create the relevant activity. During another, it remains idle with respect to that signal. The receiver does not inspect the sender's memory. It issues many LD.STRONG.GPU operations in parallel and measures how long they take. In the tested relationship, higher latency corresponds to a sender transmitting a 1 and lower latency to a sender transmitting a 0.

The protocol is simple, but the simplicity should not obscure the systems condition that makes it work. The receiver's own operations must be arranged so that a small timing change becomes visible across many measurements. The sender's activity must be frequent enough to raise the latency signal during the interval. Both sides must also agree on timing and synchronization; otherwise, a high-latency sample has no reliable relationship to a particular transmitted bit. The channel is therefore an interaction between hardware behavior and a measurement protocol, not an always-on broadcast from one instance to another.

The authors could have generated the sender's barriers by directly executing broad-scope MEMBAR instructions. For the more realistic prototype, they chose a common GPU activity instead: launching CUDA kernels. Kernel launches are useful as a side-channel source because ordinary applications perform them frequently, often far more frequently than they create or destroy CUDA contexts or call certain memory-management APIs. The paper reports roughly 19,000 kernel launches during one GPT-Neo 1.3B inference pass, compared with one tested cudaFree, 905 cudaMemcpy calls, 72 cudaMemset calls, and two context events in the same measurement. The precise counts belong to that workload and trace, but the ordering of frequencies explains the design choice.

On the H100 system used for the main experiments, the channel's capacity peaked at 1.57 Kb/s. Capacity here is not just the fastest raw bit rate. The paper accounts for bit errors using a channel-capacity measure, so a faster schedule that produces too many mistakes may be worse than a slower, cleaner schedule.

Published by DeepMox

FAQ

How does Membar+Load encode a bit?

Membar+Load encodes a 1 as higher receiver-side LD.STRONG.GPU latency and a 0 as lower latency during synchronized intervals. The sender creates the signal with repeated barriers or kernel launches, while the receiver measures its own operations.

What does the 1.57 Kb/s figure measure?

The 1.57 Kb/s figure is the peak channel capacity reported for the tested H100, accounting for bit errors rather than simply raw transmission speed. Co-running workloads reduced the reported capacity to about 0.77–1.30 kbps in tested cases.

Why is LLM model identification not arbitrary model recognition?

The demonstrated LLM attack identifies a model from a known candidate set using offline training traces; it does not show that an unseen future model can be named without comparable examples.

Previous10 minNVIDIA MIG Membars as a Cross-Instance Timing Sensor

Next12 minNVIDIA MIG Side Channels: Workloads and GPU Generations

NVIDIA MIG Membar+Load for LLM Inference

From Timing Signal to Leakage: Membar+Load and LLM Inference

A one-bit channel without shared memory

FAQ