14 ms·

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 themselve

by kimixa 5y 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 5y ago
I certainly have crashed many a machine with CUDA.
- kimixa 5y 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.

by kimixa 5y ago

waynecochran 5y ago

I certainly have crashed many a machine with CUDA.

kimixa 5y 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.