1760648 - Fuzz WebGPU shader program validation

Status: NEW

(Core :: Graphics: WebGPU, task, P3)

Description

[Jim Blandy :jimb]

We would like to exercise Firefox's WebGPU shader program validation.

Firefox's WebGPU implementation is based on the wgpu crate, which uses the Naga crate to process shader modules. Naga parses WebGPU Shading Language shaders into its own internal representation, passes them through a validator, and then uses the results of validation to generate code in the platform's shader language (SPIR-V, Metal Shading Language, or HLSL).

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.

The naga::Module type represents a parsed shader module, ready to be validated. With Naga #1668, naga::Module implements the arbitrary crate's Arbitrary trait, a standard interface that fuzzers can use to generate arbitrary Module values. A Module can be passed to naga::Validator::validate to be validated.

If validation succeeds, it produces types and other analysis results for the Module. Naga back ends accept a Module together with validation results and generate platform shader code. If we reach a point where the fuzzers are able to generate Modules that pass validation, then the Naga cli and snapshot tests provide examples of how to drive Naga back ends and produce platform shader code.

SPIR-V and HLSL both have validators that can run on Linux. Metal has a shader validator that can run on macOS. This could be used to check Naga's final output.

Comment 1

[Jim Blandy :jimb]

According to :jkratzer:

We have a very small corpus of working files that we use. Domino doesn't do any type of mutation on the shader source. That type of fuzzing I think is better handled via libfuzzer and oss-fuzz

So this is something we should undertake, and not assume that the Mozilla fuzzing team is going to cover it for us.

Comment 2

[Jim Blandy :jimb]

I think this is something close to a fuzzblocker in practice, in that it prevents us from seeing other problems. So I've bumped up this priority to P1.

Comment 3

[Jim Blandy :jimb]

If we naively use the derived implementation of the Arbitrary trait, I would expect Validator::validate_module_handles to reject almost all generated modules, simply because the handles will be wild. Granted, Validator::validate_module_handles needs fuzzing just like anything else, but it's only about 10% of the validator code.

It should be straightforward to produce Naga modules that only use valid handles. We would have a custom Arbitrary implementation for naga::Module that generates arenas using their append methods, and generates handles by using the fuzzer-provided random data to choose a handle from a set of known valid handles.

Comment 4

[Jim Blandy :jimb]

We've talked about this work a little more in terms of when we think it makes sense to begin work on this. As things stand, we have bugs being generated by the fuzzing team, and actionable high-priority bugs in our GitHub triage. Since Naga contains (almost) no unsafe code, the approach described here is less likely to reveal exploitable crashes than other exploration techniques we're already pursuing.

We decided to put this in P3 ("missing core functionality") at the bottom of the stack rank.