SideLink: The NVLink Fabric Tying Your AI Cluster Together Has a Covert Channel

Every GPU security conversation I've sat in over the past couple of years spends its energy in the same three places: the model weights, the training data, and the API keys guarding the inference endpoint. Nobody in those conversations asks a much simpler question — what's actually happening on the wire connecting the GPUs to each other? A paper out of IIT Jodhpur just gave a pretty uncomfortable answer: on NVIDIA's NVLink fabric, that wire will quietly tell a stranger what you're running, and it'll carry a message for you too, if you know how to ask.

---

NVLink Was Built to Move Data Fast, Not to Keep Secrets

NVLink is the interconnect NVIDIA uses to let GPUs inside the same server (and, via NVSwitch, across a whole rack) talk to each other directly instead of routing everything back through the CPU over PCIe. On an H200 system it moves up to 900 GB/s between GPUs — roughly 7x what PCIe Gen5 can do. That bandwidth is the entire reason multi-GPU training and large-model inference are practical at all: split a model across eight GPUs, and NVLink is what makes the shards feel like one big accelerator instead of eight separate ones shouting over a garden hose.

What NVLink was never designed to do is police who's allowed to listen. It's a shared fabric, and shared fabrics have a resource that every tenant fights over whether they know it or not: contention. When one GPU's traffic saturates a link, every other transfer sharing that link slows down, measurably, in a way any process with unprivileged access to a timer can observe. That's the entire premise this research exploits, and it isn't a new category of bug — contention-based covert channels are a decades-old idea in shared-cache and shared-bus research. What's new is that NVLink, the interconnect underpinning basically every serious AI training and inference cluster shipped in the last five years, had never been tested against it directly until now.

---

The Paper: SideLink

SideLink: Exposing NVLink to Covert- and Side-Channel Attacks, by Issa Baddour, Dip Sankar Banerjee, and Somitra Kumar Sanadhya of the Department of Computer Science and Engineering at IIT Jodhpur, was first presented as a work-in-progress paper at SPACE 2024 in Kerala, and the full study landed in the Journal of Hardware and Systems Security this year. The authors built and measured two distinct attacks on the same underlying weakness, across three GPU generations: Volta (V100), Ampere (A100), and Hopper (H200).

GPU Architecture	Test System	Covert Channel Bandwidth	Error Rate
Volta (V100)	NVLink v2	6.33 Kbps	Negligible
Ampere (A100)	DGX A100	9.90 Kbps	Negligible
Hopper (H200)	NVLink v4 / NVSwitch	8.29 Kbps	Negligible

The A100 topping the chart, ahead of the newer H200, is the detail that stuck with me. It's a reminder that "newer architecture" doesn't automatically mean "harder to eavesdrop on" — the leak is a function of link topology and scheduling behavior, not raw generation number, and DGX A100's fully-connected NVSwitch fabric apparently gives an attacker a cleaner signal than the H200's setup did in their test bed.

How a Covert Channel Rides on Wire Contention

SideLink follows the same basic recipe that this line of research (the paper builds on prior contention-based NVLink work from UC Riverside and PNNL, more on that below) has used since the first proof of concept: two mutually distrusting processes, no shared memory, no special privileges, using nothing but NVLink traffic timing as a signal. Here's the attack chain in the order it actually runs:

1. Co-locate on the same NVLink domain. The sender and receiver don't need to be on the same GPU, or even own the same VM — they just need workloads scheduled onto GPUs that share an NVLink path, which on a rented multi-GPU instance or a shared bare-metal node is the default, not an edge case.
2. Sender encodes bits as traffic, or silence. To send a 1, the sender's process issues a peer-to-peer memory copy (cudaMemcpyPeer() in the related "Beyond the Bridge" work this builds on) across the shared link, deliberately saturating it. To send a 0, it does nothing and lets the link sit idle.
3. Receiver measures its own transfer latency. The receiving process runs its own small peer-to-peer copy on a fixed schedule and times how long it takes to complete, using nothing more exotic than a CPU-side timer.
4. Contention shows up as a clean latency gap. In the reference implementation this technique traces back to, an idle link produced transfers around 28,000 clock cycles; a saturated one pushed that past 68,000 cycles — a gap wide enough to threshold cleanly into a 0 or a 1 with very low error.
5. Repeat at a fixed bit rate. String enough of these measurements together and you have a data channel that crosses a boundary — a VM boundary, a container boundary, a "we don't trust each other" boundary — that every other layer of the stack assumes is closed.

Nowhere in that chain does either side touch the other's memory, call a shared API with elevated rights, or trip anything an access-control system was built to catch. It's pure timing, on hardware that was never asked to hide it.

The Side Channel: Fingerprinting a Stranger's Workload

The covert channel needs a cooperating sender. The side-channel attack SideLink demonstrates doesn't — it just needs a victim doing normal work on a GPU that shares NVLink with the attacker. The authors collected what they describe as the first dataset of NVLink latency traces captured from real applications running on dual-GPU systems, then trained a fully connected deep-learning classifier (an FCN) on nothing but those contention patterns. Run against a dual-GPU DGX A100, it identified which application was running on the neighboring GPU with 93.1% accuracy.

Think about what that means operationally: an attacker with zero privileged access, sharing NVLink with your job by nothing more than the luck of the scheduler, can tell — with better than 9 times out of 10 confidence — whether you're fine-tuning an LLM, running batch inference, or doing something else entirely, just from how your job makes the interconnect stutter. No exfiltrated logs, no compromised container, no malware on your instance. Just pattern-matching on noise nobody thought to hide.

---

This Has Already Leaked Across Cloud VM Boundaries

SideLink isn't operating in a vacuum. It sits in a lineage of NVLink contention research out of UC Riverside and Pacific Northwest National Laboratory that's been building for two years, and the most alarming result in that lineage isn't even from the paper that triggered this piece — it's from a related follow-on called NVBleed. NVBleed's authors found that NVIDIA exposes readable performance counters (nvlink_total_data_received, nvlink_receive_throughput, and similar) with no privilege check, and that those counters leak enough signal to fingerprint applications with an F1 score up to 97.78%. Then they tested it across isolated virtual machines on Google Cloud Platform — VMs that never communicated with each other — and still measured leakage. Their own words: "there is measurable leakage even though the VMs do not communicate."

Study	Institution	Technique	Peak Bandwidth / Accuracy	Hardware Tested
Beyond the Bridge (SEED 2024)	UC Riverside / PNNL	cudaMemcpyPeer contention timing	45.5 Kbps covert channel, 3.22% error	Tesla V100
NVBleed	UC Riverside / Brookhaven / PNNL	Contention + unprivileged performance counters	70.59 Kbps covert channel; 97.78% F1 fingerprinting	DGX-1 (P100), GCP (V100), cross-VM
SideLink	IIT Jodhpur	Contention timing, no counters needed	9.90 Kbps covert channel; 93.1% fingerprinting accuracy	V100, DGX A100, H200

SideLink's bandwidth numbers look modest next to NVBleed's, and that's actually the more unsettling framing, not the less: SideLink deliberately avoided the readable performance counters and still got a clean channel out of contention alone. Counter access controls — the mitigation NVIDIA could ship fastest — don't close this gap. NVBleed's own authors tested restricting counter access as a defense and found F1 scores stayed above 40% even with rate limiting.

My Take

I've spent enough years racking servers and arguing with cloud vendors about tenancy boundaries to have a reflex here: every time someone tells me a piece of shared infrastructure is "logically isolated," I want to know exactly which layer that isolation lives at, because the answer is almost never "all of them." MIG partitions compute, cache, and HBM inside a single physical GPU. Confidential Computing on Hopper encrypts each GPU's own memory. Neither of those touches the fabric between GPUs, and until NVIDIA's Blackwell generation added NVLink link-layer encryption, that fabric carried multi-GPU traffic in the clear by design — because it was built to move tensors fast between GPUs you already trusted, in an era when "you" meant one research lab with one workload, not forty unrelated tenants renting slices of the same DGX fleet by the hour.

That's the actual story here, more than any single Kbps number: the economics of AI infrastructure moved to multi-tenant rental years before the hardware trust model caught up. GPU clouds sell you compute by the hour on shared boxes because that's the only way the unit economics work at this price point. Nobody re-engineered NVLink's isolation model to match, because until recently nobody had bothered to check whether it needed it. And even where NVIDIA has started closing the gap — Blackwell's NVLink encryption stops a passive eavesdropper from reading payload bytes off the wire — encryption doesn't touch contention timing. You can encrypt every byte crossing NVLink and this class of attack keeps working, because the signal was never the payload. It was always how long the wire took to get out of your way.

What You Should Do Right Now

• Stop assuming "multi-GPU instance" means "isolated from other tenants." If you're running anything sensitive on a rented multi-GPU node, ask your cloud provider directly whether NVLink domains on that instance type are dedicated to your tenancy or shared with others at the fabric level — not just whether the VM boundary is enforced.
• For regulated or high-value workloads, pay for dedicated NVLink domains or bare-metal. If the workload can't tolerate a co-tenant fingerprinting it, the only real mitigation available today is not sharing the fabric at all. "Isolated VM, shared interconnect" is not the same guarantee.
• Ask specifically about NVLink encryption on your hardware generation. If you're on Blackwell-class (B200/GB200) infrastructure, confirm NVLink link-layer encryption is actually enabled for your tenancy — it closes the plaintext-sniffing angle even though it won't stop contention timing.
• Restrict and monitor performance-counter access where you control the stack. If you operate DGX or NVSwitch infrastructure directly, don't leave NVLink telemetry counters world-readable to every process. It's a shallow mitigation on its own — NVBleed's own testing showed fingerprinting still worked above rate limits — but it raises the floor.
• Treat GPU scheduling as a security control, not just a performance one. If your orchestration layer (Kubernetes device plugins, Slurm, whatever you're running) can pin co-tenancy or avoid scheduling unrelated sensitive jobs onto GPUs sharing an NVLink path, that's a real lever today, and most shops aren't using it because nobody's asked them to.
• Put this on your vendor risk questionnaire. If you're procuring GPU cloud capacity for anything under compliance scope, ask the provider point-blank how NVLink-level tenant isolation works on their platform. Most won't have a rehearsed answer yet, which tells you something on its own.

---

This article was researched and drafted with AI assistance as part of an experiment in building a faster tech-writing workflow, then reviewed and edited before publishing.

---

Primary source: SideLink: Exposing NVLink to Covert- and Side-Channel Attacks — Journal of Hardware and Systems Security, Springer, 2026

Secondary source: Beyond the Bridge: Contention-Based Covert and Side Channel Attacks on Multi-GPU Interconnect — UC Riverside / PNNL, SEED 2024

Secondary source: NVBleed: Covert and Side-Channel Attacks on NVIDIA Multi-GPU Interconnect — UC Riverside / Brookhaven National Laboratory / PNNL, 2026