WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=SacJfmp33vM NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/SacJfmp33vM.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.360 --> 00:00:02.159 Hello everyone. s2 00:00:02.159 --> 00:00:07.040 This talk is about the danger of your LLMZ information leaking through shared GPU hardware. s3 00:00:07.040 --> 00:00:13.120 If 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. s4 00:00:13.120 --> 00:00:18.560 They can tell what model you're running, how fast it's responding, and even what kind of work is doing right now. s5 00:00:18.560 --> 00:00:21.600 All without touching your data, just by watching timing. s6 00:00:21.600 --> 00:00:23.039 That's what this sock covers. s7 00:00:23.039 --> 00:00:30.320 What a code tenants on the same hardware can learn about your LLM from timing alone and what you can do about it. s8 00:00:30.320 --> 00:00:35.040 To start, I'm Brian Sabbrzac, a cyber security researcher employed at Stealthium. s9 00:00:35.040 --> 00:00:41.280 At Stealthium, we specialize in securing and providing observability into the environments AI systems run on. s10 00:00:41.280 --> 00:00:44.960 My area of focus is low-level GPU related security research. s11 00:00:44.960 --> 00:00:48.079 That's something this talk covers. s12 00:00:48.079 --> 00:00:55.440 When you share a GPU between tenants, you would expect full isolation, but the isolation provided may not prove to be sufficient. s13 00:00:55.440 --> 00:01:00.559 In the case of this attack, the attacker doesn't even need any special permissions like root access. s14 00:01:00.559 --> 00:01:02.960 It doesn't need any traditional exploit either. s15 00:01:02.960 --> 00:01:09.119 The only thing it does is time the parts of the hardware that still shared among tenants. s16 00:01:09.119 --> 00:01:14.159 This is a demonstration video of what the victims and the attackers dashboards look like. s17 00:01:14.159 --> 00:01:17.520 On the left, we have quentry model doing. s18 00:01:17.520 --> 00:01:22.640 On the right, the attacker uses a side channel that quentry leaks into as it's running. s19 00:01:22.640 --> 00:01:29.360 From that it determines exactly what model it is and what kind of text is producing right now. s20 00:01:30.080 --> 00:01:33.280 These are just the headline claims but not the whole story. s21 00:01:33.280 --> 00:01:38.159 We can tell which model it is architecture and depth within 97% accuracy. s22 00:01:38.159 --> 00:01:42.479 We can tell how fast is the coding within 99.3% accuracy. s23 00:01:42.479 --> 00:01:47.600 We can tell when and how much the busy periods token counts and the answer length. s24 00:01:47.600 --> 00:01:54.000 What we can tell what kind of work it's doing, codes, J pros, JSON or retrieval. s25 00:01:54.000 --> 00:02:00.000 What we cannot tell though are the actual prompts, answers or contents, just timing. s26 00:02:00.000 --> 00:02:05.040 And all of these on real H100s serving real LLMs. s27 00:02:05.119 --> 00:02:11.680 If you're using Nvidia hardware, GPU isolation is achieved using multi instant GPU or MIG for short. s28 00:02:11.680 --> 00:02:20.560 Each isolated MAG slice has its own physical compute units and dedicated VRM that provides hardware isolation on those parts. s29 00:02:20.560 --> 00:02:26.720 In our example, the LLM we're serving runs on a slice with three compute units and 40 GB of VM. s30 00:02:26.720 --> 00:02:32.160 The attack runs on just one compute units and 10 GB of VM. s31 00:02:32.959 --> 00:02:38.480 What's isolated are compute units, memory capacity, bandwidth quotas, and false errors. s32 00:02:38.480 --> 00:02:41.200 The L2 cache is partitioned per instance too. s33 00:02:41.200 --> 00:02:43.519 There's no cross instance eviction. s34 00:02:43.519 --> 00:02:45.599 So it's not shared in that sense. s35 00:02:45.599 --> 00:02:49.920 The actual leaks are memory barriers or members which are GPU wide. s36 00:02:49.920 --> 00:02:54.879 One instances barrier still touches every L2 partition on the card. s37 00:02:54.879 --> 00:02:58.400 Timing is the one thing that isn't isolated. s38 00:02:58.400 --> 00:03:03.440 So when one tenant is busy, the other tenants owns get slightly slower. s39 00:03:03.440 --> 00:03:10.800 The key point is the a GPUwide memory barrier takes effect in every L2 partition on the card. s40 00:03:10.800 --> 00:03:15.920 The next slide builds the whole attack on that one fact. s41 00:03:16.560 --> 00:03:20.879 The vector is that the attacker only ever reads its own memory. s42 00:03:20.879 --> 00:03:22.400 It only times its own reads. s43 00:03:22.400 --> 00:03:24.319 It never touches the victim's memory. s44 00:03:24.319 --> 00:03:25.440 There are three steps. s45 00:03:25.440 --> 00:03:29.920 All from its own small buffer, time the load and repeat every five microsconds. s46 00:03:29.920 --> 00:03:34.480 This primitive and the MIG member leak itself isn't our discovery. s47 00:03:34.480 --> 00:03:40.080 Credit goes to the researchers behind behind bars at using security. s48 00:03:40.080 --> 00:03:43.360 A big thanks for their work. s49 00:03:44.159 --> 00:03:50.799 Now try looking at the timing differences with the naked eye comparing your tenant idle versus serving an LLM. s50 00:03:50.799 --> 00:03:53.120 You wouldn't even be able to discern them. s51 00:03:53.120 --> 00:03:56.080 The median latency is only three microsconds higher. s52 00:03:56.080 --> 00:04:00.159 To the attacker though, those three microsconds are all it needs. s53 00:04:00.159 --> 00:04:05.439 That's enough to gather all the information we already talked about. s54 00:04:06.000 --> 00:04:10.959 Quentry with 8 billion parameters is running on the victim slice throughout this one. s55 00:04:10.959 --> 00:04:13.840 All captured data was taken from a live model. s56 00:04:13.840 --> 00:04:17.840 At the top is GPU activity over time, one burst per token. s57 00:04:17.840 --> 00:04:21.600 Below is the frequency spectrum of the attackers on latency trace. s58 00:04:21.600 --> 00:04:32.880 There 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. s59 00:04:33.919 --> 00:04:37.360 This is a real trace one token in the time domain. s60 00:04:37.360 --> 00:04:40.400 The token shows a total of 39 bumps. s61 00:04:40.400 --> 00:04:47.759 The bumps with green peaks are the layer invocations while orange ones are additional between layer processing. s62 00:04:47.759 --> 00:04:55.680 In a later slide, we will demonstrate how we determine the actual layer counts even with those extra bumps are present. s63 00:04:55.680 --> 00:04:58.000 Here we look at the decode speed itself. s64 00:04:58.000 --> 00:05:02.000 Just by timing, we found the token ray completely bind. s65 00:05:02.000 --> 00:05:06.080 So speed alone is something an attacker can recover accurately. s66 00:05:06.080 --> 00:05:08.800 But speed by itself isn't a clean fingerprints. s67 00:05:08.800 --> 00:05:15.440 Quentry 8 billion and llama 38 billion they quote only 1.6% apart in their token rate. s68 00:05:15.440 --> 00:05:18.560 So from speed alone, you'd think they're the same model. s69 00:05:18.560 --> 00:05:21.280 It narrows things down, but it doesn't nail it. s70 00:05:21.280 --> 00:05:22.639 We need something sharper. s71 00:05:22.639 --> 00:05:23.759 Layer counts. s72 00:05:23.759 --> 00:05:27.440 That's what the next few slides get into. s73 00:05:27.520 --> 00:05:30.960 We use the same fold and average stick from before. s74 00:05:30.960 --> 00:05:34.720 This time we run it once per model instead of once per token. s75 00:05:34.720 --> 00:05:40.000 What comes out is a bit count that lands almost exactly on a whole number. s76 00:05:40.000 --> 00:05:44.639 The mean distance from an integer across 22 traces is just 0.028. s77 00:05:44.639 --> 00:05:45.840 0 to8. s78 00:05:45.840 --> 00:05:46.800 That's the tell. s79 00:05:46.800 --> 00:05:54.560 If this were just a fixed hardware artifact divided by different token rates, we'd expect factions, not whole numbers. s80 00:05:54.560 --> 00:06:02.479 Each count works out to the model's layer count plus one to true, one to three additional picss. s81 00:06:03.039 --> 00:06:08.240 Every model keeps its own signal fingerprints, a mix of tempo and harmonic structure. s82 00:06:08.240 --> 00:06:11.360 To be clear, this is not a trained machine learning classifier. s83 00:06:11.360 --> 00:06:14.400 There's no training set, no labels, no configuration. s84 00:06:14.400 --> 00:06:16.319 It's under 30 lines of code. s85 00:06:16.319 --> 00:06:20.400 The method checks each candidate's depth from 16 to 48. s86 00:06:20.400 --> 00:06:26.000 It measures how strongly that depth's expected signature shows up in the real trace. s87 00:06:26.000 --> 00:06:34.400 Then it picks whichever of its best for quen 8 billion 36 layers wins clearly by four point times over the next candidate. s88 00:06:34.400 --> 00:06:37.520 Because this is a best fit test, not a lookup table. s89 00:06:37.520 --> 00:06:40.479 It also works to models it never seen before. s90 00:06:40.479 --> 00:06:44.000 That includes proprietary on unreleased ones. s91 00:06:44.000 --> 00:06:50.240 since there's nothing it needs to have seen in the first place. s92 00:06:52.080 --> 00:06:54.160 And this works surprisingly well. s93 00:06:54.160 --> 00:06:57.759 The layer fit classifier also outputs the confidence level. s94 00:06:57.759 --> 00:07:04.800 Across our testing, only two least confident answers ended up being wrong ones. s95 00:07:06.000 --> 00:07:12.400 This same method also picks up fine tunes and distillations that that share the same base model. s96 00:07:12.400 --> 00:07:16.720 That's because the architecture and layer count carry over unchanged. s97 00:07:16.720 --> 00:07:19.599 Take three related models as an example. s98 00:07:19.599 --> 00:07:22.639 Llama 38 billion from meta has 32 layers. s99 00:07:22.639 --> 00:07:35.360 Llama 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. s100 00:07:35.360 --> 00:07:42.800 The per layer timing comes out to only 1.6 600 seconds median latency shifts of each other. s101 00:07:42.800 --> 00:07:45.599 The rest of the signal looks the same. s102 00:07:45.599 --> 00:07:50.880 Regardless of this, our classifier is still able to discern between them. s103 00:07:50.880 --> 00:07:53.440 Now we ask a deeper question on the same channel. s104 00:07:53.440 --> 00:07:56.240 Not which model, but what is doing right now? s105 00:07:56.240 --> 00:07:58.000 We look at four workload types. s106 00:07:58.000 --> 00:08:00.560 Pros, code, JSON, and retrieval. s107 00:08:00.560 --> 00:08:05.520 We give a work that's on every half second based on the last 5 seconds of timing. s108 00:08:05.520 --> 00:08:14.720 out of 40 half second words with 31 rights and four full responses were correctly identified by majority votes. s109 00:08:14.720 --> 00:08:20.080 This is the same classifier from the video earlier misses included. s110 00:08:20.080 --> 00:08:25.039 One condition is worth stating this was measured with speculative decoding turned on. s111 00:08:25.039 --> 00:08:27.919 That's an optin in VLM, not the default. s112 00:08:27.919 --> 00:08:28.960 Here's the mechanism. s113 00:08:28.960 --> 00:08:34.560 How predictable the text is changes how many drafted tokens get accepted at each step. s114 00:08:34.560 --> 00:08:38.959 that changes step time and that's the signal we're picking up. s115 00:08:38.959 --> 00:08:44.959 We tested 11 configurations dense and mixture of experts BF16 and FB8. s116 00:08:44.959 --> 00:08:49.760 The same figure page showed up every time just at very different strengths. s117 00:08:49.760 --> 00:08:56.320 70.2% spread on GPT or 20 billion versus 0.9% on GLM 49 billion. s118 00:08:56.320 --> 00:09:01.519 10 out of 11 round pros fastest when the chance alone would only give you one in four. s119 00:09:01.519 --> 00:09:08.880 So say the attacker already knows the model from the earlier slides and specular quality happens to be on. s120 00:09:08.880 --> 00:09:12.480 It can also tell what kind of text is coming out. s121 00:09:12.480 --> 00:09:15.600 Now we take the shade chip out of the picture entirely. s122 00:09:15.600 --> 00:09:19.200 MLG needs the attacker on the same physical die. s123 00:09:19.200 --> 00:09:20.800 This attack doesn't. s124 00:09:20.800 --> 00:09:27.120 The setup here is an eight times H100 server connected over an MV switch fabric. s125 00:09:27.120 --> 00:09:31.279 The victim runs tens of parallel across GPU 0ero and one. s126 00:09:31.279 --> 00:09:36.880 The attacker just needs any other GPU in that same server, GPU 2 in this case. s127 00:09:36.880 --> 00:09:40.160 Per access over NV switch is a real intended feature. s128 00:09:40.160 --> 00:09:44.800 It's how multi-GPU jobs normally work, not a bug being abused. s129 00:09:44.800 --> 00:09:49.920 MLG tensor parallelism also can't coexist on the same device. s130 00:09:49.920 --> 00:09:57.120 So this is really a different population of deployments, not just the same attack repeated. s131 00:09:58.000 --> 00:10:07.279 The probe runs on GPU 2. It pointer traases memory that actually is on GPU0 over envelop along the way. s132 00:10:07.279 --> 00:10:11.680 An idle hop takes about 890 nconds. s133 00:10:11.680 --> 00:10:17.120 Once the victim starts working that climbs up to 300 microsconds. s134 00:10:17.120 --> 00:10:24.959 These are three half seconds me captures and you can actually count the tokens by eye. s135 00:10:24.959 --> 00:10:31.360 What we lose compared to MLG is the layer bit is below the noise at this distance. s136 00:10:31.360 --> 00:10:39.200 So over envelink the fingerprints we we're left with is mostly tempo not layer counts. s137 00:10:39.200 --> 00:10:43.040 Here we test the five models on identical serving setup. s138 00:10:43.040 --> 00:10:46.560 Only the model itself gives away which one it is. s139 00:10:46.560 --> 00:10:50.240 This method gives 79.2% accuracy. s140 00:10:50.240 --> 00:10:53.760 Now it fails exactly where you'd expect the tempo to fail. s141 00:10:53.760 --> 00:11:06.160 Llama 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. s142 00:11:06.160 --> 00:11:13.519 The takeaway is that the envel worse than MG's since it loses the layer bit. s143 00:11:13.519 --> 00:11:16.480 But worse signal to noise ratio isn't the same as safety. s144 00:11:16.480 --> 00:11:23.440 79% against a 20% baseline is still real fingerprints not noise. s145 00:11:23.680 --> 00:11:25.279 First, some good news. s146 00:11:25.279 --> 00:11:29.200 Our own product at work called the attack straight out of the box. s147 00:11:29.200 --> 00:11:40.160 Delty 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. s148 00:11:40.160 --> 00:11:42.480 Here is what's made this one stand out. s149 00:11:42.480 --> 00:11:51.920 A single kernel relaunched about 3,000 times, hitting the exact same 40 kilobytes of memory over and over instead of moving to new data. s150 00:11:51.920 --> 00:12:00.640 only one kilobte of data was sent back to the CPU the entire time because the timing itself was the payload not the output. s151 00:12:00.640 --> 00:12:07.440 In real terms that is under 600 milliseconds start to finish with fewer than 50 tokens of a reply. s152 00:12:07.440 --> 00:12:12.560 We quot it before the response was ever half typed. s153 00:12:14.320 --> 00:12:15.920 So three takeaways. s154 00:12:15.920 --> 00:12:19.120 First placement is something operators actually control. s155 00:12:19.120 --> 00:12:21.279 So do not put an untrusted tenants. s156 00:12:21.279 --> 00:12:25.120 MIG slides right next to sensitive model. s157 00:12:25.120 --> 00:12:26.720 Second, know the trade-off. s158 00:12:26.720 --> 00:12:32.880 MIG rules out peer-to-peer communication, meaning there is no tens of parallelism on MIG. s159 00:12:32.880 --> 00:12:39.519 Sharding over envels what leaks to timing alone rather than the layer counts. s160 00:12:39.519 --> 00:12:42.639 Third, watch the C GPU itself. s161 00:12:42.639 --> 00:12:49.839 Make sure the host infrastructure is actively verifying that no malicious workloads are running on the hardware. s162 00:12:49.839 --> 00:12:55.920 That's exactly what Seltium does by catching these probes straight from the Chrome behavior. s163 00:12:56.959 --> 00:13:02.480 Sharing a GPU means timing alone can give away the model, the speed and the workload. s164 00:13:02.480 --> 00:13:07.040 That's true even across envelink without needing any exploit at all. s165 00:13:07.040 --> 00:13:09.120 Deltium sees this happen in real time. s166 00:13:09.120 --> 00:13:12.720 Most organizations still don't have that kind of visibility. s167 00:13:12.720 --> 00:13:16.240 Thanks again to the researchers of Behind Bars. s168 00:13:16.240 --> 00:13:18.880 This whole talk builds upon their work. s169 00:13:18.880 --> 00:13:21.600 Thank you all for watching.