Problems related to tracking data dependencies during fuzzing

Hi @saelo, I am recently integrating some WebAssembly (abbreviated as Wasm) features into fuzzilli. Everything looks good to me when adjusting the static JS model. However, when I try to add some primitive code generators, the problem surfaces.

Consider the generation of a WebAssembly.Exception object, according to the specification, its construction requires two parameters:

• A WebAssembly.Tag object which specifies the shape of the WebAssembly.Exception object;
• A jsArray object that carries the real payload of the exception, where each value in the payload must match the type specified in the WebAssembly.Tag object, otherwise a TypeError is thrown;

A demonstrating example could be as follow, here i32 stands for JS numbers and i64 stands for JS BigInt:

const tag = new WebAssembly.Tag({ parameters: ["i32", "i64"] });
const exception1 = new WebAssembly.Exception(tag, [42, 100n]);        // ok
const exception2 = new WebAssembly.Exception(tag, [42, 100]);         // TypeError: Cannot convert 100 to a BigInt

Suppose we would like to construct a WebAssembly.Exception object via, let's say, CodeGenerator, we may write the following code:

CodeGenerator("WasmExceptionGenerator", inputs: .required(.jsWebAssemblyTagObject)) {
  // ... some code here ...
}

However, since variables inside Fuzzilli do not explicitly track the data stored inside them, we could not determine the shape of the passed-in input inside the generator. Thus, there is no way for us to construct an appropriate payload to the WebAssembly.Exception constructor, or we can only resort to the guard statement but that's generally not desired.

Theoretically, maybe we can use the DefUseAnalyzer to track the data sources of the input, but that could bring extra overhead to the fuzzing process. Currently I cannot come up with an elegant way to handle this problem so I open this issue to see if you can give any advices (since I am not 100% familiar with fuzzilli). Thanks in advance for any kind suggestions ;).

Start by reading the CodeGenerator example, the jsWebAssemblyTagObject input type, and DefUseAnalyzer references described in the issue. Determine how generator inputs could expose the WebAssembly.Tag shape needed to construct a matching payload, and define a workable approach without relying on guards or excessive fuzzing overhead.