Bug 1746250 Comment 17 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Jim Mathies [:jimm] from comment #11)

So here's the state of play:

We have four entry points that are worth fuzzing. Ordered from 'front'
(content JS) to 'back' (platform graphics APIs), they are:

- Fuzzing the WebGPU JS API, as defined in
  [`WebGPU.webidl`](https://searchfox.org/mozilla-central/source/dom/webidl/WebGPU.webidl)

  Covered by bug fuzzing-webgpu.

  Fuzzing is running. Fuzzblockers are P1 tasks for Jim.

- Fuzzing the WebGPU IPDL protocol, as defined in
  [`PWebGPU.ipdl`](`https://searchfox.org/mozilla-central/source/dom/webgpu/ipc/PWebGPU.ipdl)

  Covered by bug 1760666.

  IPDL fuzzing is still experimental. As of this writing, Christian (decoder) is
  running it locally on his machines, but it can't be scaled in its current form.
  Bug 1760666 covers implementing this once the harness is ready.

- Fuzzing the WebGPU Shading Language (WGSL) front end, in the Naga crate.

  Covered by bug 1750019.

  To some extent this is already covered by JS API fuzzing: if the fuzzer can
  create an Adapter and a Device, then calls to `Device::createShaderModule`
  talk to the WGSL front end pretty directly. However, I think it would still be
  valuable to fuzz the Naga crate directly.

- Fuzzing the WGSL validator, in the Naga crate.

  Covered by bug 1760648.

  Naga is straightforward to use in isolation, without Firefox or even wgpu.
  Fuzzing Naga directly would give the fuzzer better access to complex code that
  is crucial to WebGPU's safety story. See that bug for more details.

There are the GitHub issues
[naga#1704](https://github.com/gfx-rs/naga/issues/1704) and
[naga#1668](https://github.com/gfx-rs/naga/pull/1668), but we don't really have
control over the open-source project's priorities. I think Mozilla should track
its own work in Bugzilla, as suggested above.
(In reply to Jim Mathies [:jimm] from comment #11)

So here's the state of play:

We have four entry points that are worth fuzzing. Ordered from 'front' (content JS) to 'back' (platform graphics APIs), they are:

- Fuzzing the WebGPU JS API, as defined in [`WebGPU.webidl`](https://searchfox.org/mozilla-central/source/dom/webidl/WebGPU.webidl)

  Covered by bug fuzzing-webgpu.

  Fuzzing is running. Fuzzblockers are P1 tasks for Jim.

- Fuzzing the WebGPU IPDL protocol, as defined in [`PWebGPU.ipdl`](`https://searchfox.org/mozilla-central/source/dom/webgpu/ipc/PWebGPU.ipdl)

  Covered by bug 1760666.

  IPDL fuzzing is still experimental. As of this writing, Christian (decoder) is running it locally on his machines, but it can't be scaled in its current form. Bug 1760666 covers implementing this once the harness is ready.

- Fuzzing the WebGPU Shading Language (WGSL) front end, in the Naga crate.

  Covered by bug 1750019.

  To some extent this is already covered by JS API fuzzing: if the fuzzer can create an Adapter and a Device, then calls to `Device::createShaderModule` talk to the WGSL front end pretty directly. However, I think it would still be valuable to fuzz the Naga crate directly.

- Fuzzing the WGSL validator, in the Naga crate.

  Covered by bug 1760648.

  Naga is straightforward to use in isolation, without Firefox or even wgpu. Fuzzing Naga directly would give the fuzzer better access to complex code that is crucial to WebGPU's safety story. See that bug for more details.

There are the GitHub issues [naga#1704](https://github.com/gfx-rs/naga/issues/1704) and [naga#1668](https://github.com/gfx-rs/naga/pull/1668), but we don't really have control over the open-source project's priorities. I think Mozilla should track its own work in Bugzilla, as suggested above.
(In reply to Jim Mathies [:jimm] from comment #11)

So here's the state of play:

We have four entry points that are worth fuzzing. Ordered from 'front' (content JS) to 'back' (platform graphics APIs), they are:

- Fuzzing the WebGPU JS API, as defined in [`WebGPU.webidl`](https://searchfox.org/mozilla-central/source/dom/webidl/WebGPU.webidl)

  Covered by bug [fuzzing-webgpu](https://bugzilla.mozilla.org/show_bug.cgi?id=fuzzing-webgpu).

  Fuzzing is running. Fuzzblockers are P1 tasks for Jim.

- Fuzzing the WebGPU IPDL protocol, as defined in [`PWebGPU.ipdl`](`https://searchfox.org/mozilla-central/source/dom/webgpu/ipc/PWebGPU.ipdl)

  Covered by bug 1760666.

  IPDL fuzzing is still experimental. As of this writing, Christian (decoder) is running it locally on his machines, but it can't be scaled in its current form. Bug 1760666 covers implementing this once the harness is ready.

- Fuzzing the WebGPU Shading Language (WGSL) front end, in the Naga crate.

  Covered by bug 1750019.

  To some extent this is already covered by JS API fuzzing: if the fuzzer can create an Adapter and a Device, then calls to `Device::createShaderModule` talk to the WGSL front end pretty directly. However, I think it would still be valuable to fuzz the Naga crate directly.

- Fuzzing the WGSL validator, in the Naga crate.

  Covered by bug 1760648.

  Naga is straightforward to use in isolation, without Firefox or even wgpu. Fuzzing Naga directly would give the fuzzer better access to complex code that is crucial to WebGPU's safety story. See that bug for more details.

There are the GitHub issues [naga#1704](https://github.com/gfx-rs/naga/issues/1704) and [naga#1668](https://github.com/gfx-rs/naga/pull/1668), but we don't really have control over the open-source project's priorities. I think Mozilla should track its own work in Bugzilla, as suggested above.

Back to Bug 1746250 Comment 17