Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LeftoverLocals: Listening to LLM responses through leaked GPU local memory

blog.trailofbits.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#31

Post by htrp »

Retr0id wrote: post #30
ComputerGuru wrote: post #14

At this point, I assume this is the default and don’t expect data recovery to not be provide on the same physical machine (even across virtualization barriers). If your data is that sensitive, run it on dedicated hardware. Papering over this with mitigation over mitigation is a fool’s errand: both a genuine waste of compute resources and guaranteed to be a game of cat and mouse.

This is certainly the pragmatic approach to GPU memory in 2024, but I don't think it's a fool's errand. It's a solved problem on the CPU side of things, and I don't see any reason why we can't solve it in the GPU domain too. Notably: > NVIDIA: confirmed that their devices are not currently impacted > ARM: also confirmed that their devices are not currently impacted.

TIL that ARM has GPUs

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#32

Post by kridsdale1 »

frankjr wrote: post #9

> Since September 2023, we have been working with CERT (..) > Apple: Despite multiple efforts to establish contact through CERT/CC, we only received a response from Apple on January 13, 2024. > Apple did not respond or engage with us regarding the disclosure. Well at least they are consistent at not giving a flying f*ck about working with bug reporters, no matter who you are. I have reported 5+ radars in the past and…

My first job post college was a Radar triager for specific Apple frameworks. I was 23 or so, probably high the previous evening, and I did not give a FUCK about some external developer and their problems.

Sorry. That was a long time ago.

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#33

Post by kridsdale1 »

bee_rider wrote: post #21
Veserv wrote: post #3

tl;dr GPU drivers made by various vendors do not sanitize compute unit hardware scratch memory between uses, so you can just freely read whatever the last user left laying around when they stopped. Literally too incompetent to follow even basic security 101 practices. A time shared device must be sanitized between users to prevent state leakage. There is no reason to believe that a security culture that clueless when…

These designs all come out of the consumer and gaming space. They correctly trade security away for performance. Blame whoever started running untrustworthy code on them. These vulnerabilities will continue happening. What I don’t understand is how anybody can be surprised at this point. If anyone out there missed the first dozen instances of this: workloads on modern hardware can’t be isolated.

Yeah it’s pretty insane that the entire AI hype and crypto hype industry waves are actually just getting really specific pixel shaders to sparkle in extremely specific ways.

The gear was made to frag noobs in Counterstrike at 300 FPS.

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#34

Post by malf »

Retr0id wrote: post #30
ComputerGuru wrote: post #14

At this point, I assume this is the default and don’t expect data recovery to not be provide on the same physical machine (even across virtualization barriers). If your data is that sensitive, run it on dedicated hardware. Papering over this with mitigation over mitigation is a fool’s errand: both a genuine waste of compute resources and guaranteed to be a game of cat and mouse.

This is certainly the pragmatic approach to GPU memory in 2024, but I don't think it's a fool's errand. It's a solved problem on the CPU side of things, and I don't see any reason why we can't solve it in the GPU domain too. Notably: > NVIDIA: confirmed that their devices are not currently impacted > ARM: also confirmed that their devices are not currently impacted.

> It's a solved problem on the CPU side of things

Is it? gestures at pile of cpu bugs

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#35

Post by formerly_proven »

dmvdoug wrote: post #13

Is this the Golden Age of hardware vulnerabilities?

At some point in the last ~20 years a lot of people started interpreting "this system is meant to protect against programming errors crashing the whole system" as "this is a watertight security boundary and I can rely on zero information leaking across". The results are, uh, roughly what you'd expect.

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#36

Post by ks6g10 »

Retr0id wrote: post #30
ComputerGuru wrote: post #14

At this point, I assume this is the default and don’t expect data recovery to not be provide on the same physical machine (even across virtualization barriers). If your data is that sensitive, run it on dedicated hardware. Papering over this with mitigation over mitigation is a fool’s errand: both a genuine waste of compute resources and guaranteed to be a game of cat and mouse.

This is certainly the pragmatic approach to GPU memory in 2024, but I don't think it's a fool's errand. It's a solved problem on the CPU side of things, and I don't see any reason why we can't solve it in the GPU domain too. Notably: > NVIDIA: confirmed that their devices are not currently impacted > ARM: also confirmed that their devices are not currently impacted.

The reason why arm is not affected is that their "local" memory is non existent and they just spill everything to cache.

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#37

Post by pjmlp »

bee_rider wrote: post #21
Veserv wrote: post #3

tl;dr GPU drivers made by various vendors do not sanitize compute unit hardware scratch memory between uses, so you can just freely read whatever the last user left laying around when they stopped. Literally too incompetent to follow even basic security 101 practices. A time shared device must be sanitized between users to prevent state leakage. There is no reason to believe that a security culture that clueless when…

These designs all come out of the consumer and gaming space. They correctly trade security away for performance. Blame whoever started running untrustworthy code on them. These vulnerabilities will continue happening. What I don’t understand is how anybody can be surprised at this point. If anyone out there missed the first dozen instances of this: workloads on modern hardware can’t be isolated.

They incorrectly trade security for performance, in the days of money transactions in games, esports, and server dependencies.

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#38

Post by ngneer »

dmvdoug wrote: post #25
ngneer wrote: post #19

Earlier quoted context omitted.

Kind of. However, I would venture most real world attack scenarios do not leverage HW vulnerabilities. But wait, how do we know what is happening invisibly? And what about state actors? The answer is we do not know, but the economics do not change based on whether an attack is made visible or not. Attacks tend to follow and reveal the path of least impedance. If software attacks are working fine for most, why would a…

I just feel like maybe 20 years ago people thought the hardware was the hardware and all the security issues were inevitably to be found in software. I mean, I know that people who work with hardware for a living always say that hardware has always been shit, but it really does feel now like everything is a security vulnerability, in a way that people weren’t looking for previously. Then again, maybe they were, and I…

You are right. These days the lower layers are explored in greater detail. There was a noticeable shift over the last decade or so in mainstream security research. HW security has always been a subject of study, but there is renewed interest in microarchitectural attacks since the late 2010's, when speculative execution was shown vulnerable.

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#39

Post by declaredapple »

hhh wrote: post #29
declaredapple wrote: post #15

GPU memory isolation is generally really bad, from between processes and entire virtual machines. Does anyone know if nvidia's virtual gpus improve the isolation at all?

IIRC it only improves if you use MIG.

So I guess only the A30/A100/H100 then?

Re: LeftoverLocals: Listening to LLM responses through leaked GPU local memory

#40

Post by bee_rider »

pjmlp wrote: post #37
bee_rider wrote: post #21

Earlier quoted context omitted.

These designs all come out of the consumer and gaming space. They correctly trade security away for performance. Blame whoever started running untrustworthy code on them. These vulnerabilities will continue happening. What I don’t understand is how anybody can be surprised at this point. If anyone out there missed the first dozen instances of this: workloads on modern hardware can’t be isolated.

They incorrectly trade security for performance, in the days of money transactions in games, esports, and server dependencies.

I built a trampoline out of laptops, but I hurt my knee, I don’t know why Dell insists on making these dangerously sharp and hard trampoline parts.
Post reply on HN