As a developer, I need to have fuzzing testing for gossip messages so I can be sure decoding is safe and correct

[akoptelov]

• Implement fuzzing tests for binprot decoding #6
• Differential fuzzing for gossip messages #8
• Structure-aware fuzzing?
• Fuzzing CI

See #1

[akoptelov]

Fuzzing CI:

• Servers
• Patched Mina Image (for diff fuzzing)
• Coverage reporting
• GitHub integration (to restart on new changes)

[akoptelov]

Regarding differential fuzzing. Currently we're using IPC to access OCaml-side decoder. That is because various troubles using Mina via FFI in Rust. Alternative way is to launch Rust fuzzer from OCaml instead. Some questions here:

• Will we gain any performance improvement here (probably yes, because of less copying)?
• Will we get OCaml coverage feedback for fuzzer?
• How much work will it take to add more Rust stuff to Mina?

@tizoc and @dkuehr Can you answer any of these questions?

[tizoc]

@akoptelov I am thinking that for the linking issues, even if the fuzzer is launched from OCaml there may still be issues related to having various Rust components (our own, and o1labs proof-system) that don't know about each other (because they are compiled separately) but that depend on common code fail. So we probably need a proper solution and not just a workaround.

Regarding 1), maybe, but my guess is that the communication overhead is probably little compared to the work being done. Also, I am thinking that with IPC we can use multiple processes to have parallelism that would not be possible otherwise?

Regarding 2), I remember that for Tezedge @dkuehr did something, so he probably has something to say.

Regarding 3), right now there will be issues, but once the linking issue has been solved and I have figured what a proper setup should look like I don't think it should be hard. One thing I am not entirely sure is what will happen with the WASM target and linking + FFI (I guess it is doable, I am just not very familiar with how the WASM-target building process works)

[dkuehr]

Let me elaborate on question #2. You are asking about coverage feedback, so for the specific case of fuzzcheck-rs the short answer is no. In Tezedge what I did was to add coverage reports for OCaml components by making a few modifications to bisect-ppx and rebuilding the project with it.

In a nutshell bisect-ppx doesn't do more than modifying the target's code AST and adding the needed counters and providing functions to reset/dump them. This is somewhat similar to what other compilers (Rust) can do to generate code with gcov but they are incompatible approaches. It is "easy" for tools like fuzzcheck-rs to read the gcov generated counters from memory on-the-fly and get feedback that way, but not so for the bisect-ppx ones because it works on a "higher" level. It could be possible to make to modify fuzzcheck-rs and bisect-ppx to make all this work but IMHO it is too much effort.

That said, some fuzzers have the ability to work with coverage at lower-level, for example if you use hongfuzz you can use CPU-level tracing (BTS and/or IntelPT), in this case you don't even need to compile the target with coverage information What you get is basically lists of instruction-pointer addresses of the assembly instructions that are hit during execution. Decent coverage reports could be generated if the target has debug symbols. Note that you will need a CPU that supports this (most modern Intel CPUs).