[HN Gopher] A Driver on the GPU
___________________________________________________________________
A Driver on the GPU
Author : sph
Score : 52 points
Date : 2022-04-27 08:03 UTC (1 days ago)
(HTM) web link (www.basnieuwenhuizen.nl)
(TXT) w3m dump (www.basnieuwenhuizen.nl)
| robert_foss wrote:
| This is wonderfully perverse.
| spacemanmatt wrote:
| I'm not well-versed on GPU architecture. Can someone help out
| with a gloss-over? I read that something is being pushed-down
| from CPU/host territory into GPU territory but I'm not quite
| clear what the deltas are.
| bnieuwen wrote:
| A random attempt:
|
| Typically the application wants to draw stuff on the GPU. To do
| this it calls into the GPU driver, which builds a big memory
| buffer in some implementation-defined format that instructs the
| GPU what to do, and then the driver instructs the GPU to
| execute that.
|
| However, applications these days want to do some of the work to
| determine which commands to do on the GPU (e.g. culling).
|
| So the work here is to allow the application to create a memory
| buffer on the GPU with commands using a standardized format and
| then the driver has to convert that into the implementation-
| defined format on the GPU. This copies a lot of the complexity
| of the driver from the CPU to something running on the GPU.
| waynecochran wrote:
| 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 wrote:
| Going back less than a month the most recent macOS update
| patched a graphics driver vulnerability.
| https://support.apple.com/en-us/HT213220
| waynecochran wrote:
| 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 wrote:
| There have been exploits and there will probably be more in the
| future, see e.g.
| https://googleprojectzero.blogspot.com/2020/09/attacking-qua...
| kimixa wrote:
| 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.
| charcircuit wrote:
| I believe there was a point in time where you could use the GPU
| on the 3DS to read / write anywhere in memory.
___________________________________________________________________
(page generated 2022-04-28 23:01 UTC)