abrown opened issue #4268:
In the
differential_v8
fuzz target, the oracle retrieves the first exported memory and checks that the memory contents are the same between Wasmtime and V8. To properly enable shared memory in this fuzz target, we would need to check whether the first exported memory is shared and if so:
- use
get_shared_memory()
instead ofget_memory()
in the Wasmtime API- use
SharedArrayBuffer
instead ofArrayBuffer
in the V8 API
cfallin commented on issue #4268:
As a high-level question: how are we planning to do differential checking in the presence of nondeterminism if/when our generated fuzz tests include actual spawning of multiple threads?
I can see a few possibilities:
- We only ever fuzz single-threaded programs that happen to use shared memory primitives. Definitely better than nothing, but not a super-strong claim to a robust implementation on its own, I guess?
- We somehow try to enforce the same interleavings (nondeterministic choices in the memory model) between differential oracle and execution-under-test. Also seems difficult, implies heavy instrumentation (Valgrind-style)...
- We generate test programs in a way that, by construction, ensures determinism. I'm not sure exactly what this would look like but it seems like the least bad of the options: basically we have some framework/skeleton of generated program into which wasm-smith plugs arbitrary code, but the overall framework is designed to not have data races, etc (parallel loop or somesuch).
- Something else?
alexcrichton labeled issue #4268:
In the
differential_v8
fuzz target, the oracle retrieves the first exported memory and checks that the memory contents are the same between Wasmtime and V8. To properly enable shared memory in this fuzz target, we would need to check whether the first exported memory is shared and if so:
- use
get_shared_memory()
instead ofget_memory()
in the Wasmtime API- use
SharedArrayBuffer
instead ofArrayBuffer
in the V8 API
alexcrichton commented on issue #4268:
Personally I have no ideas beyond your first bullet. I don't know how to fuzz a multithreaded system for correctness really other than custom one-off programs which we can verify that "when compiled to wasm and run this should always work.
alexcrichton edited a comment on issue #4268:
Personally I have no ideas beyond your first bullet. I don't know how to fuzz a multithreaded system for correctness really other than custom one-off programs which we can verify that "when compiled to wasm and run this should always work".
Last updated: Nov 22 2024 at 16:03 UTC