go-fuzz support

[dvyukov]

go-fuzz is a fuzzer for Go:
https://github.com/dvyukov/go-fuzz

Since oss-fuzz aimed at supporting multiple fuzzers, go-fuzz support should be possible and would be useful.

go-fuzz contains 70 fuzzers for Go std lib and other popular packages but there is no story for continous running:
https://github.com/dvyukov/go-fuzz/tree/master/examples

[mikea]

There are two areas:

• build system. This should be the easiest. As long as a docker image provides binaries in /out/, we are game. We don't care how the binary was produced.
• ClusterFuzz. I am not sure how much need to be changed in CF to add a new type of fuzzer. @oliverchang

[dvyukov]

@Dor1s

[dvyukov]

FTR, issue about fuzzing support in Go:
golang/go#19109

[dvyukov]

We need to ensure that Go fuzzing support will be integratable with OSS-Fuzz or it will be a bold fail if we later realize that it's poorly suitable for setups like OSS-Fuzz.

[dvyukov]

@thepudds @josharian

Ideally Go additional of a new Go target boils down to listing the import path (e.g. github.com/google/oss-fuzz). Everything else should be infer-able/covered by conventions.

For Go we potentially have fuzzer engine and target as 2 separate binaries (it may not work well to have the engine in the intrumented binary). We should be able to support this, right? We can have the engine as the binary and target as data dependency of the binary, right?

What flags/features OSS-Fuzz needs from a fuzzing engine? Anything special?

FTR, there is a proposal with Go flags:
https://docs.google.com/document/u/1/d/1zXR-TFL3BfnceEAWytV8bnzB2Tfp6EPFinWVJ5V4QC8/pub

[Dor1s]

Yay! I'm sure it's all doable, we just need to plan some time for doing that. //cc @inferno-chromium

We should be able to support this, right? We can have the engine as the binary and target as data dependency of the binary, right?

Yes, AFL works in a similar way and we use it fine.

What flags/features OSS-Fuzz needs from a fuzzing engine? Anything special?

We'll need crash stacktraces, distinct crash signatures for different crash types, crash minimization, performance stats (speed, coverage, corpus units, etc), something else I can't think off the top of my head.

The way it works now (and probably will keep working) is that we have a launcher script for every fuzzing engine. CF calls that launcher script (there is a fairly simple interface that needs to be implemented), and the script interacts with the fuzzing engine (e.g. provides proper CMD line, runs it, does some log parsing, etc). //cc @oliverchang

[dvyukov]

Thanks. Looks like we should not have any major problems then.
We could prototype OSS-Fuzz support later when Go fuzzing support takes shape... or maybe now using @thepudds prototype golang/go#19109 (comment)

We'll need crash stacktraces, distinct crash signatures for different crash types,

This should be extractable from raw crash in the wrapper script.

crash minimization

The plan is that Go fuzzer will save already minimized crashes, so this can be no-op. And this should be optional anyway.

performance stats (speed, coverage, corpus units, etc)

No concrete plan for this. But assuming this is optional.

[Dor1s]

This can be considered done. Further work is being tracked as #2714