search

wgslfuzz / darthshader

Apache License 2.0
21 stars 6 forks source link

Mesa integration? #2

Open DemiMarie opened 1 month ago

DemiMarie commented 1 month ago

Mesa can generate CPU code via LLVM, as well as GPU code for a variety of GPUs. This compiler is exposed via Vulkan and OpenGL, so I am wondering if the shader fuzzer could call into OpenGL or Vulkan so that Mesa could be fuzzed too.

wgslfuzz commented 1 month ago

Generally speaking, yes. One would need to develop a harness for Mesa. One question here is to what degree Mesa can handle invalid inputs. E.g., are bugs found by mutating the OpenGL AST in-scope? When developing a harness, the threat model must be considered otherwise too many false positives will surface. Do you have anything in mind already?

DemiMarie commented 1 month ago

Generally speaking, yes. One would need to develop a harness for Mesa. One question here is to what degree Mesa can handle invalid inputs. E.g., are bugs found by mutating the OpenGL AST in-scope? When developing a harness, the threat model must be considered otherwise too many false positives will surface. Do you have anything in mind already?

My threat model is basically the same as yours: untrusted shaders from WebGPU. The idea here is for Mesa to be an alternative back-end compiler to DXC. Mesa goes all the way to CPU or GPU machine code, rather than stopping at DXBC, so there is significantly more attack surface that can be fuzzed.

wgslfuzz commented 1 month ago

Well, for this scenario I have a (private) harness already :) It does find bugs, some have been reported upstream already. I'll consider publishing my harness once the current set of findings is resolved. Don't hold your breath though, sadly there seems to be very little interest from upstream into fixing those bugs.

wgslfuzz commented 1 month ago

Example report of a memory safety violation, currently non-public but for future reference: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11449

DemiMarie commented 1 month ago

Well, for this scenario I have a (private) harness already :) It does find bugs, some have been reported upstream already. I'll consider publishing my harness once the current set of findings is resolved. Don't hold your breath though, sadly there seems to be very little interest from upstream into fixing those bugs.

I suggest submitting them to the ChromeOS bug bounty program. They will care if one can exploit the Chrome GPU process from the web, and ChromeOS uses Mesa for its user-mode GPU drivers.

wgslfuzz commented 1 month ago

I suggest submitting them to the ChromeOS bug bounty program. They will care if one can exploit the Chrome GPU process from the web, and ChromeOS uses Mesa for its user-mode GPU drivers.

Well, that is pretty much what I did: I compiled Mesa for Ubuntu with ASAN enabled (the exact Mesa version shipped by ChromeOS) and crafted an HTML that triggers an ASAN violation when opened (with ASAN chrome + ASAN Mesa). Granted, showing the issue on Ubuntu is not ideal. So I tried to use a chromebook; ran into issues getting ASAN chromium to start though. Only ASAN Chromium can, generally speaking, load ASAN Mesa, because the Mesa .so must import the ASAN symbols from the main executable.

Investing more time and attempting to demonstrate the issue on a chromebook directly is feasible, but neither was this requested in the ticket nor do I think the limited activity in the bug tracker warrants more effort. It is a bit of an unfortunate situation.

DemiMarie commented 1 month ago

Investing more time and attempting to demonstrate the issue on a chromebook directly is feasible, but neither was this requested in the ticket nor do I think the limited activity in the bug tracker warrants more effort. It is a bit of an unfortunate situation.

Did you submit this directly to Google, in addition to (or, for future issues, instead of) Mesa GitLab?

wgslfuzz commented 1 month ago

Yes. For future reference see (currently hidden) issue https://issuetracker.google.com/u/1/issues/361027508