3 ms·

I think browsers are sandboxed even for GPU access. But I am now curious if persistent tracking can be done using GPU memory due to warm reboot resilience.

baybal2 7y ago
The sandboxing ends as soon the browser calls the GL library, and you have really no control whatsoever of what will be happening after that. Up until very, very recently, driver coders had no idea at all that GPU instructions can be used offensively, and it is still common for buggy GPU code to crash your program/driver/os or the GPU itself. Sandboxing is nearly useless when you let so much executable code through it.
- theamk 7y ago
  GL library is pretty high level, so most of the functions are safe. You don’t in general specify direct GPU instructions to run, instead it is large things like “apply transform” GL does allow uploading some code to card sometimes, in form of shaders for example, but this is fairly constrained and limited language.
  - AstralStorm 7y ago
    Unfortunately there are some ancient but still supported old OpenGL extensions that could allow arbitrary code execution on GPU. New ones too. E.g. uploading a fake "already compiled" shader binary in OpenGL 4 via glProgramBinary. I'd be surprised if these are actually validated. (Well more than a CRC plus length. On GCN it is CRC32. On Intel's, some hacked SHA256-alike.) SPIR-V probably is better checked, but I wouldn't trust it farther than I can throw it. There's too many vendor and architecture specific extensions.
fao_ 7y ago
> I think browsers are sandboxed even for GPU access. But I am now curious if persistent tracking can be done using GPU memory due to warm reboot resilience. You probably seen this, but in case you haven't: https://arstechnica.com/information-technology/2017/02/now-sites-can-fingerprint-you-online-even-when-you-use-multiple-browsers/ https://arstechnica.com/information-technology/2017/02/now-s...
- badrabbit 7y ago
  I have not heard of that specific technique. Thanks.
fulafel 7y ago
WebGL specifies that memory is always pre-zeroed. There were implementation bugs in this in the early days though.

baybal2 7y ago

The sandboxing ends as soon the browser calls the GL library, and you have really no control whatsoever of what will be happening after that. Up until very, very recently, driver coders had no idea at all that GPU instructions can be used offensively, and it is still common for buggy GPU code to crash your program/driver/os or the GPU itself. Sandboxing is nearly useless when you let so much executable code through it.

theamk 7y ago
GL library is pretty high level, so most of the functions are safe. You don’t in general specify direct GPU instructions to run, instead it is large things like “apply transform” GL does allow uploading some code to card sometimes, in form of shaders for example, but this is fairly constrained and limited language.
- AstralStorm 7y ago
  Unfortunately there are some ancient but still supported old OpenGL extensions that could allow arbitrary code execution on GPU. New ones too. E.g. uploading a fake "already compiled" shader binary in OpenGL 4 via glProgramBinary. I'd be surprised if these are actually validated. (Well more than a CRC plus length. On GCN it is CRC32. On Intel's, some hacked SHA256-alike.) SPIR-V probably is better checked, but I wouldn't trust it farther than I can throw it. There's too many vendor and architecture specific extensions.

fao_ 7y ago

> I think browsers are sandboxed even for GPU access. But I am now curious if persistent tracking can be done using GPU memory due to warm reboot resilience. You probably seen this, but in case you haven't: https://arstechnica.com/information-technology/2017/02/now-sites-can-fingerprint-you-online-even-when-you-use-multiple-browsers/ https://arstechnica.com/information-technology/2017/02/now-s...

badrabbit 7y ago
I have not heard of that specific technique. Thanks.

fulafel 7y ago

WebGL specifies that memory is always pre-zeroed. There were implementation bugs in this in the early days though.