How does the wasm-opt ensure the generated Wasm is valid and free from undefined behaviors?

[Shawdox]

When using the wasm-opt to generate random Wasm binary:

wasm-opt -ttf [random_file] -o generated_wasm.wasm

I checked the source code and found the main build function is TranslateToFuzzReader::build(). How does wasm-opt ensure that the generated Wasm is valid? Can there be undefined behavior in this?

[kripken]

The wasm file is a valid wasm file, in the sense that it validates in Binaryen, and should validate in all wasm VMs, unless we have a bug (please report it, if so).

Wasm itself does not have undefined behavior. The closest is nondeterminism in NaNs. The fuzzer does have some logic to handle that, it can do a "de-NaN" operation (search for NAN in scripts/fuzz_opt.py) to avoid NaNs at runtime, making the output fully deterministic.

(Other issues exist like infinite loops which are not undefined behavior, but can be a problem when fuzzing. The fuzzer also has logic to prevent that, see addHangLimitChecks().)

[Shawdox]

Thanks for the reply! But I think actually some UBs like float-divided-by-zero, float-cast-overflow and null-deference still happend in Wasm. And if there is no UB in Wasm binaries, why Emscripten provides UBSan during compiling?

[kripken]

Float division by zero is not undefined behavior in wasm: it results in a NaN.

Null dereference in the sense of loading a value from address 0 results in the value at that address: in wasm there is nothing special about address 0 compared to address 10240. (And reading from a pointer that is greater than the size of memory will trap.)

Emscripten provides UBSan for C's benefit, not wasm's. C has UB, and in wasm that UB will do something defined, but logically it remains UB for C, and so there are tools to handle it. For comparison, C has UB but when C is compiled to ARM CPU instructions, those CPU instructions are concrete operations, and UB is not relevant for them (at least not in themselves). Wasm is the same as ARM here. If you wrote a fuzzer for ARM, you would also not have UB to think about.

[tlively]

As @kripken described, there is no UB in Wasm, but there are traps. For example, dividing an integer by 0 or accessing out-of-bounds memory will trap. This is not UB because it is well-defined behavior in the Wasm spec, but it is still something that normal programs would avoid. Programs generated by the fuzzer can trap, although we try to generate code patterns that will avoid trapping where possible.