Your GPU Neighbor Can Hear Your Model — Branislav Brzak, Stealthium

AI Engineer · 13 min · 169 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

1. 00:01Hello everyone.
2. 00:02This talk is about the danger of your LLMZ information leaking through shared GPU hardware.
3. 00:07If you're running a model in the cloud on a GPU you share with other tenants, someone next to you can learn things about it.
4. 00:13They can tell what model you're running, how fast it's responding, and even what kind of work is doing right now.
5. 00:18All without touching your data, just by watching timing.
6. 00:21That's what this sock covers.
7. 00:23What a code tenants on the same hardware can learn about your LLM from timing alone and what you can do about it.
8. 00:30To start, I'm Brian Sabbrzac, a cyber security researcher employed at Stealthium.
9. 00:35At Stealthium, we specialize in securing and providing observability into the environments AI systems run on.
10. 00:41My area of focus is low-level GPU related security research.
11. 00:44That's something this talk covers.
12. 00:48When you share a GPU between tenants, you would expect full isolation, but the isolation provided may not prove to be sufficient.
13. 00:55In the case of this attack, the attacker doesn't even need any special permissions like root access.
14. 01:00It doesn't need any traditional exploit either.
15. 01:02The only thing it does is time the parts of the hardware that still shared among tenants.
16. 01:09This is a demonstration video of what the victims and the attackers dashboards look like.
17. 01:14On the left, we have quentry model doing.
18. 01:17On the right, the attacker uses a side channel that quentry leaks into as it's running.
19. 01:22From that it determines exactly what model it is and what kind of text is producing right now.
20. 01:30These are just the headline claims but not the whole story.
21. 01:33We can tell which model it is architecture and depth within 97% accuracy.
22. 01:38We can tell how fast is the coding within 99.3% accuracy.
23. 01:42We can tell when and how much the busy periods token counts and the answer length.
24. 01:47What we can tell what kind of work it's doing, codes, J pros, JSON or retrieval.
25. 01:54What we cannot tell though are the actual prompts, answers or contents, just timing.
26. 02:00And all of these on real H100s serving real LLMs.
27. 02:05If you're using Nvidia hardware, GPU isolation is achieved using multi instant GPU or MIG for short.
28. 02:11Each isolated MAG slice has its own physical compute units and dedicated VRM that provides hardware isolation on those parts.
29. 02:20In our example, the LLM we're serving runs on a slice with three compute units and 40 GB of VM.
30. 02:26The attack runs on just one compute units and 10 GB of VM.
31. 02:32What's isolated are compute units, memory capacity, bandwidth quotas, and false errors.
32. 02:38The L2 cache is partitioned per instance too.
33. 02:41There's no cross instance eviction.
34. 02:43So it's not shared in that sense.
35. 02:45The actual leaks are memory barriers or members which are GPU wide.
36. 02:49One instances barrier still touches every L2 partition on the card.
37. 02:54Timing is the one thing that isn't isolated.
38. 02:58So when one tenant is busy, the other tenants owns get slightly slower.
39. 03:03The key point is the a GPUwide memory barrier takes effect in every L2 partition on the card.
40. 03:10The next slide builds the whole attack on that one fact.
41. 03:16The vector is that the attacker only ever reads its own memory.
42. 03:20It only times its own reads.
43. 03:22It never touches the victim's memory.
44. 03:24There are three steps.
45. 03:25All from its own small buffer, time the load and repeat every five microsconds.
46. 03:29This primitive and the MIG member leak itself isn't our discovery.
47. 03:34Credit goes to the researchers behind behind bars at using security.
48. 03:40A big thanks for their work.
49. 03:44Now try looking at the timing differences with the naked eye comparing your tenant idle versus serving an LLM.
50. 03:50You wouldn't even be able to discern them.
51. 03:53The median latency is only three microsconds higher.
52. 03:56To the attacker though, those three microsconds are all it needs.
53. 04:00That's enough to gather all the information we already talked about.
54. 04:06Quentry with 8 billion parameters is running on the victim slice throughout this one.
55. 04:10All captured data was taken from a live model.
56. 04:13At the top is GPU activity over time, one burst per token.
57. 04:17Below is the frequency spectrum of the attackers on latency trace.
58. 04:21There is a fundamental at 81 Hz which is just tokens per second plus harmonics since each token is a mix of distinct frequencies not one clean one.
59. 04:33This is a real trace one token in the time domain.
60. 04:37The token shows a total of 39 bumps.
61. 04:40The bumps with green peaks are the layer invocations while orange ones are additional between layer processing.
62. 04:47In a later slide, we will demonstrate how we determine the actual layer counts even with those extra bumps are present.
63. 04:55Here we look at the decode speed itself.
64. 04:58Just by timing, we found the token ray completely bind.
65. 05:02So speed alone is something an attacker can recover accurately.
66. 05:06But speed by itself isn't a clean fingerprints.
67. 05:08Quentry 8 billion and llama 38 billion they quote only 1.6% apart in their token rate.
68. 05:15So from speed alone, you'd think they're the same model.
69. 05:18It narrows things down, but it doesn't nail it.
70. 05:21We need something sharper.
71. 05:22Layer counts.
72. 05:23That's what the next few slides get into.
73. 05:27We use the same fold and average stick from before.
74. 05:30This time we run it once per model instead of once per token.
75. 05:34What comes out is a bit count that lands almost exactly on a whole number.
76. 05:40The mean distance from an integer across 22 traces is just 0.028.
77. 05:440 to8.
78. 05:45That's the tell.
79. 05:46If this were just a fixed hardware artifact divided by different token rates, we'd expect factions, not whole numbers.
80. 05:54Each count works out to the model's layer count plus one to true, one to three additional picss.
81. 06:03Every model keeps its own signal fingerprints, a mix of tempo and harmonic structure.
82. 06:08To be clear, this is not a trained machine learning classifier.
83. 06:11There's no training set, no labels, no configuration.
84. 06:14It's under 30 lines of code.
85. 06:16The method checks each candidate's depth from 16 to 48.
86. 06:20It measures how strongly that depth's expected signature shows up in the real trace.
87. 06:26Then it picks whichever of its best for quen 8 billion 36 layers wins clearly by four point times over the next candidate.
88. 06:34Because this is a best fit test, not a lookup table.
89. 06:37It also works to models it never seen before.
90. 06:40That includes proprietary on unreleased ones.
91. 06:44since there's nothing it needs to have seen in the first place.
92. 06:52And this works surprisingly well.
93. 06:54The layer fit classifier also outputs the confidence level.
94. 06:57Across our testing, only two least confident answers ended up being wrong ones.
95. 07:06This same method also picks up fine tunes and distillations that that share the same base model.
96. 07:12That's because the architecture and layer count carry over unchanged.
97. 07:16Take three related models as an example.
98. 07:19Llama 38 billion from meta has 32 layers.
99. 07:22Llama 3.18 billion also from meta uses that same 32 layer backbone with minor upgrades and R1 is still llama 8 billion from deepseek is an improvements on top of that.
100. 07:35The per layer timing comes out to only 1.6 600 seconds median latency shifts of each other.
101. 07:42The rest of the signal looks the same.
102. 07:45Regardless of this, our classifier is still able to discern between them.
103. 07:50Now we ask a deeper question on the same channel.
104. 07:53Not which model, but what is doing right now?
105. 07:56We look at four workload types.
106. 07:58Pros, code, JSON, and retrieval.
107. 08:00We give a work that's on every half second based on the last 5 seconds of timing.
108. 08:05out of 40 half second words with 31 rights and four full responses were correctly identified by majority votes.
109. 08:14This is the same classifier from the video earlier misses included.
110. 08:20One condition is worth stating this was measured with speculative decoding turned on.
111. 08:25That's an optin in VLM, not the default.
112. 08:27Here's the mechanism.
113. 08:28How predictable the text is changes how many drafted tokens get accepted at each step.
114. 08:34that changes step time and that's the signal we're picking up.
115. 08:38We tested 11 configurations dense and mixture of experts BF16 and FB8.
116. 08:44The same figure page showed up every time just at very different strengths.
117. 08:4970.2% spread on GPT or 20 billion versus 0.9% on GLM 49 billion.
118. 08:5610 out of 11 round pros fastest when the chance alone would only give you one in four.
119. 09:01So say the attacker already knows the model from the earlier slides and specular quality happens to be on.
120. 09:08It can also tell what kind of text is coming out.
121. 09:12Now we take the shade chip out of the picture entirely.
122. 09:15MLG needs the attacker on the same physical die.
123. 09:19This attack doesn't.
124. 09:20The setup here is an eight times H100 server connected over an MV switch fabric.
125. 09:27The victim runs tens of parallel across GPU 0ero and one.
126. 09:31The attacker just needs any other GPU in that same server, GPU 2 in this case.
127. 09:36Per access over NV switch is a real intended feature.
128. 09:40It's how multi-GPU jobs normally work, not a bug being abused.
129. 09:44MLG tensor parallelism also can't coexist on the same device.
130. 09:49So this is really a different population of deployments, not just the same attack repeated.
131. 09:58The probe runs on GPU 2. It pointer traases memory that actually is on GPU0 over envelop along the way.
132. 10:07An idle hop takes about 890 nconds.
133. 10:11Once the victim starts working that climbs up to 300 microsconds.
134. 10:17These are three half seconds me captures and you can actually count the tokens by eye.
135. 10:24What we lose compared to MLG is the layer bit is below the noise at this distance.
136. 10:31So over envelink the fingerprints we we're left with is mostly tempo not layer counts.
137. 10:39Here we test the five models on identical serving setup.
138. 10:43Only the model itself gives away which one it is.
139. 10:46This method gives 79.2% accuracy.
140. 10:50Now it fails exactly where you'd expect the tempo to fail.
141. 10:53Llama 3.5 8 billion and R1 is still are both 8 billion models that the code three hertz apart so they blur together where MIG's layer counts would have separate them easily.
142. 11:06The takeaway is that the envel worse than MG's since it loses the layer bit.
143. 11:13But worse signal to noise ratio isn't the same as safety.
144. 11:1679% against a 20% baseline is still real fingerprints not noise.
145. 11:23First, some good news.
146. 11:25Our own product at work called the attack straight out of the box.
147. 11:29Delty monitors every single kernel launch across every GPU, analyzes suspicious workloads, and runs them through a full alert pipeline, which is something not every vendor can do.
148. 11:40Here is what's made this one stand out.
149. 11:42A single kernel relaunched about 3,000 times, hitting the exact same 40 kilobytes of memory over and over instead of moving to new data.
150. 11:51only one kilobte of data was sent back to the CPU the entire time because the timing itself was the payload not the output.
151. 12:00In real terms that is under 600 milliseconds start to finish with fewer than 50 tokens of a reply.
152. 12:07We quot it before the response was ever half typed.
153. 12:14So three takeaways.
154. 12:15First placement is something operators actually control.
155. 12:19So do not put an untrusted tenants.
156. 12:21MIG slides right next to sensitive model.
157. 12:25Second, know the trade-off.
158. 12:26MIG rules out peer-to-peer communication, meaning there is no tens of parallelism on MIG.
159. 12:32Sharding over envels what leaks to timing alone rather than the layer counts.
160. 12:39Third, watch the C GPU itself.
161. 12:42Make sure the host infrastructure is actively verifying that no malicious workloads are running on the hardware.
162. 12:49That's exactly what Seltium does by catching these probes straight from the Chrome behavior.
163. 12:56Sharing a GPU means timing alone can give away the model, the speed and the workload.
164. 13:02That's true even across envelink without needing any exploit at all.
165. 13:07Deltium sees this happen in real time.
166. 13:09Most organizations still don't have that kind of visibility.
167. 13:12Thanks again to the researchers of Behind Bars.
168. 13:16This whole talk builds upon their work.
169. 13:18Thank you all for watching.