Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Couldn't it possibly lead to arbitrary code execution on the GPU, with that opening the floodgates towards the rest of the system via DMA, or maybe even enabling the dropping of some payload for the kernel mode GPU driver?


Only if an attacker can (1) identify a piece of exploitable data that the GPU firmware or kernel mode portion of the driver relies on, (2) ascertain its location at runtime, and (3) obtain a physically adjacent block of memory.

I'm not certain that something which satisfies 1, let alone 3, necessarily exists. On the CPU you flip some bits related to privilege levels. Are any analogous and similarly exploitable data structures maintained by common GPU firmware? And if so, is such data stored in the bulk VRAM?

It wouldn't surprise me if it was possible but it also seems entirely unrealistic given that either you are restricted to an API such as webgl (gl;hf) or you have native access in which case you have better options available to you seeing as the driver stacks are widely rumored to be security swiss cheese (if you doubt this look at how much effort google has invested in sandboxing the "real" GPU driver away from apps on chromeos).


(1) go for the root page table protection/ownership bits? These are often predictably located(but don't have to be). But getting access near them probably seems difficult.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: