3 ms·

Just curious, are there exploits involving the GPU in the wild? It seems there is a lot of surface area for attack when emitting command buffers to the GPU. Not

Just curious, are there exploits involving the GPU in the wild? It seems there is a lot of surface area for attack when emitting command buffers to the GPU. Not that I know how to get at system critical resources via the GPU, but there are some clever bastards out there.

ianlevesque 4y ago
Going back less than a month the most recent macOS update patched a graphics driver vulnerability. https://support.apple.com/en-us/HT213220 https://support.apple.com/en-us/HT213220
- waynecochran 4y ago
  That seems to be a more generic issue with access of out-of-bounds region of memory which other (non-graphics) drivers could also do.
bnieuwen 4y ago
There have been exploits and there will probably be more in the future, see e.g. https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html https://googleprojectzero.blogspot.com/2020/09/attacking-qua...
kimixa 4y ago
All modern GPUs (Or at least both I've worked on professionally) have MMUs and some context privilege level (IE so contexts can't change the MMU state themselves to escape) in hardware. If that is busted all bets are off, similar to how if the CPU has issues in the same area. The security model of the GPU itself doesn't really allow any level of security within the context - if you can write shader code (e.g. massage the glsl/hlsl into doing what you want, or just upload a binary shader of your own) you already can read anything mapped into that context. I think there's some systems that add stricter validation onto those shaders to disallow things like out-of-bounds reads, and that may have bugs that will cause issues if any security relies on that - e.g. for browsers when sourcing shaders from webgl, or anything where untrusted sources share the same context as possible private info. But that's built on top of the GPU driver's model itself, and provides a restricted model to it's clients. This would just be another thing they disallow. This "Driver in the GPU" will just be code ran in that context already, so I don't see it as increasing the attack surface. It may be an issue if people start wanting finer grain permissions within a context, however.
- waynecochran 4y ago
  I certainly have crashed many a machine with CUDA.
  - kimixa 4y ago
    My understanding is that with current generation GPUs a crash/timeout can happen. Again, you can do pretty much anything with shaders, so invalid accesses, infinite loops, other things that can halt execution are perfectly possible. It doesn't mean much in the way of security. But they should be detected and that context killed (or reset in a way that may lose the current job's state) - all other contexts should keep their state. Though task switching is often a lot cruder than on CPUs, so during that timeout other tasks may be blocked - so other renders (including the window system) will be wedged until it's reset. This may mean that a bad actor with access to the GPU can try a denial of service style attack, throwing constant bad tasks at the GPU and causing it to wedge repeatedly, which can certainly be annoying.
charcircuit 4y ago
I believe there was a point in time where you could use the GPU on the 3DS to read / write anywhere in memory.
- monocasa 4y ago
  Yeah, the 3DS's GPU doesn't have an MMU.

ianlevesque 4y ago

Going back less than a month the most recent macOS update patched a graphics driver vulnerability. https://support.apple.com/en-us/HT213220 https://support.apple.com/en-us/HT213220

waynecochran 4y ago
That seems to be a more generic issue with access of out-of-bounds region of memory which other (non-graphics) drivers could also do.

bnieuwen 4y ago

There have been exploits and there will probably be more in the future, see e.g. https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html https://googleprojectzero.blogspot.com/2020/09/attacking-qua...

kimixa 4y ago

All modern GPUs (Or at least both I've worked on professionally) have MMUs and some context privilege level (IE so contexts can't change the MMU state themselves to escape) in hardware. If that is busted all bets are off, similar to how if the CPU has issues in the same area. The security model of the GPU itself doesn't really allow any level of security within the context - if you can write shader code (e.g. massage the glsl/hlsl into doing what you want, or just upload a binary shader of your own) you already can read anything mapped into that context. I think there's some systems that add stricter validation onto those shaders to disallow things like out-of-bounds reads, and that may have bugs that will cause issues if any security relies on that - e.g. for browsers when sourcing shaders from webgl, or anything where untrusted sources share the same context as possible private info. But that's built on top of the GPU driver's model itself, and provides a restricted model to it's clients. This would just be another thing they disallow. This "Driver in the GPU" will just be code ran in that context already, so I don't see it as increasing the attack surface. It may be an issue if people start wanting finer grain permissions within a context, however.

waynecochran 4y ago
I certainly have crashed many a machine with CUDA.
- kimixa 4y ago
  My understanding is that with current generation GPUs a crash/timeout can happen. Again, you can do pretty much anything with shaders, so invalid accesses, infinite loops, other things that can halt execution are perfectly possible. It doesn't mean much in the way of security. But they should be detected and that context killed (or reset in a way that may lose the current job's state) - all other contexts should keep their state. Though task switching is often a lot cruder than on CPUs, so during that timeout other tasks may be blocked - so other renders (including the window system) will be wedged until it's reset. This may mean that a bad actor with access to the GPU can try a denial of service style attack, throwing constant bad tasks at the GPU and causing it to wedge repeatedly, which can certainly be annoying.

charcircuit 4y ago

I believe there was a point in time where you could use the GPU on the 3DS to read / write anywhere in memory.

monocasa 4y ago
Yeah, the 3DS's GPU doesn't have an MMU.