Open akoptelov opened 2 years ago
Fuzzing CI:
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:
@tizoc and @dkuehr Can you answer any of these questions?
@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)
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).
See #1