You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
wgpu is a Web-exposed, privileged attack surface. Furthermore, it passes mostly-untrusted input to GPU shader compilers not designed for this. This is well-known to be a problem, but DarthShader (a GPU shader fuzzer) provides a potential solution.
Describe the solution you'd like
wgpu should use DarthShader to fuzz both wgpu itself and all supported backends, including:
Furthermore, DarthShader should be extended to run the resulting shaders and compare results, to ensure that the drivers are not miscompiling shaders in a potentially security-critical way.
Describe alternatives you've considered
I am not aware of other alternatives that do not leave users vulnerable to attacks. This does not mean that such alternatives do not exist.
On Linux, it may be possible to use the virtio-GPU native context infrastructure to run Mesa in a per-site process that is extremely tightly sandboxed (with no access to the filesystem, network, or windowing system), or even to compile it to WebAssembly.
Additional context
GPU userspace drivers are not security boundaries.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
wgpu is a Web-exposed, privileged attack surface. Furthermore, it passes mostly-untrusted input to GPU shader compilers not designed for this. This is well-known to be a problem, but DarthShader (a GPU shader fuzzer) provides a potential solution.
Describe the solution you'd like
wgpu should use DarthShader to fuzz both wgpu itself and all supported backends, including:
Furthermore, DarthShader should be extended to run the resulting shaders and compare results, to ensure that the drivers are not miscompiling shaders in a potentially security-critical way.
Describe alternatives you've considered
I am not aware of other alternatives that do not leave users vulnerable to attacks. This does not mean that such alternatives do not exist.
On Linux, it may be possible to use the virtio-GPU native context infrastructure to run Mesa in a per-site process that is extremely tightly sandboxed (with no access to the filesystem, network, or windowing system), or even to compile it to WebAssembly.
Additional context
GPU userspace drivers are not security boundaries.
The text was updated successfully, but these errors were encountered: