[HN Gopher] LeftoverLocals: Listening to LLM responses through l...
___________________________________________________________________
LeftoverLocals: Listening to LLM responses through leaked GPU local
memory
Author : ks6g10
Score : 63 points
Date : 2024-01-16 17:58 UTC (5 hours ago)
(HTM) web link (blog.trailofbits.com)
(TXT) w3m dump (blog.trailofbits.com)
| Veserv wrote:
| 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 developing a universally
| shared, high criticality device can be believed if they claim to
| do better elsewhere. Their process is either so incompetent or so
| inconsistent that their claims can not be believed without
| external audits.
|
| In this case: Apple, Qualcomm, AMD, Imagination.
|
| Edit: Added Imagination as noted by reply.
| vlovich123 wrote:
| And Imagination.
|
| Notably Intel and Nvidia were not impacted. I wonder if the
| security hardening that Google worked on with Nvidia for Stadia
| helped prevent this
| kevingadd wrote:
| Could imagine it being related to CUDA as well. Memory being
| consistently zero-initialized helps prevent application bugs.
| vlovich123 wrote:
| Maybe but multi tenant GPU use cases only really come up
| for cloud and cloud GPU popularity is only a little more
| recent.
| Veserv wrote:
| Jeez, I hope it did not require "security hardening" for
| Nvidia to do something this basic. If these other vendors
| missed some tiny corner resulting in state leakage, that
| would be understandable. But, forgetting to clear local
| memory is just inexcusable.
|
| Imagine a OS forgetting to replace your general purpose
| registers across context switches. Only a rank incompetent
| and useless security process would let something like that
| get all the way through to deployment.
| vlovich123 wrote:
| Vendors have consistently ignored multi tenant issues when
| coding because gaming doesn't need it and cloud
| traditionally hasn't used GPUs all that much.
|
| You'd be surprised by how many security issues exist in GPU
| drivers
| ks6g10 wrote:
| Could probably be that the shared memory (at least in the
| past) also was used for cache, so the same mechanism that
| probably sanitizer the cache is/was in play here.
| jmgao wrote:
| Google used AMD GPUs for Stadia, not NVIDIA.
| vlovich123 wrote:
| Eventually for the product. My memory may be faulty but I
| talked with engineers working on it during development and
| I'm pretty sure the initial development was on Nvidia.
| kevingadd wrote:
| Wasn't too long ago that stray texture data would be left lying
| around from other processes, too. You could exploit that to
| read the contents of the user's banking tabs and stuff like
| that.
| dist-epoch wrote:
| It's not so simple.
|
| For example Windows takes over GPU memory control, it
| virtualizes it, and allocates it to various applications, zeros
| it, etc...
| ks6g10 wrote:
| This is specific to local/scratch memory which is not exposed
| for allocation in the same way dram is.
| bee_rider wrote:
| 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.
| Kab1r wrote:
| I've been told that historically performance has been prioritized
| over security in the GPU space. Mitigating things like this does
| incur a performance penalty.
| jiripospisil wrote:
| > 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 have never received any
| response, not even a confirmation.
| dmvdoug wrote:
| Is this the Golden Age of hardware vulnerabilities?
| ngneer wrote:
| 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 anyone
| spend more on weaponizing a HW exploit?
| ComputerGuru wrote:
| 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.
| declaredapple wrote:
| 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?
| jeroenhd wrote:
| This is one of my main concerns with technologies like WebGPU.
| Luckily, WebGPU seems to sacrifice some performance to keep
| attacks like these from working:
| https://github.com/trailofbits/LeftoverLocalsRelease/tree/ma...
| dang wrote:
| Url changed from https://leftoverlocals.com/, which points to
| this and has more information.
___________________________________________________________________
(page generated 2024-01-16 23:00 UTC)