Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: support continuously running fuzzing with OSS-Fuzz #50192

Open
katiehockman opened this issue Dec 15, 2021 · 4 comments
Open

cmd/go: support continuously running fuzzing with OSS-Fuzz #50192

katiehockman opened this issue Dec 15, 2021 · 4 comments

Comments

@katiehockman
Copy link
Member

@katiehockman katiehockman commented Dec 15, 2021

Motivation

Currently, OSS-Fuzz supports continuously fuzzing go-fuzz targets in its libfuzzer build mode. There is no OSS-Fuzz support for native fuzz targets, meaning that a developer must fully manage the execution of a fuzz test, directly from the command line. In many cases, this will mean running fuzzing as a background process, or on a separate machine.

This is insufficient for many use cases. It can often take several days to several months for fuzzing to discover a crash. Even if a crash is found quickly, OSS-Fuzz can do a better job of promptly reporting the crash to the interested parties.

We should make the necessary changes in the standard library to support the integration of native fuzzing with OSS-Fuzz, and partner with the OSS-Fuzz team to hook it up.

Two main approaches come to mind for how to support this:

Option 1: Go native fuzzing supports a libFuzzer mode.

This could be available through a new -fuzzengine flag, e.g.:

$ go test -fuzz=Fuzz -fuzzengine=libfuzzer

This will create an ELF file which will be linkable by libFuzzer for native fuzz targets.
This can likely be heavily based on go114-fuzz-build, which performs a similar task, just for go-fuzz targets instead of native targets.

Using this with -c could look something like this:

$ go test -c -fuzz=FuzzPng -fuzzengine=libfuzzer
$ clang FuzzPng.a -o FuzzPng -fsanitize=fuzzer
$ ./FuzzPng corpus

We will need to create a template, much like the template in go114-fuzz-build, which will export a LLVMFuzzerTestOneInput function which can be used by libFuzzer for each mutation.

The template in go114-fuzz-build is fairly straightforward, since a go-fuzz target can take the []byte provided by libFuzzer directly. This will be more involved for the native support, since it’s exported targets take a *testing.F, and the fuzz target is not defined until f.Fuzz is called.

This will be more complicated for structured data as well, however it should still be possible since libFuzzer can be turned into a structure-aware fuzzing engine.

Option 2: OSS-Fuzz integrates with native fuzzing directly

Native support could be integrated into OSS-Fuzz directly. This would likely not be straightforward from the OSS-Fuzz side, and it’s unclear how much effort would be required for this from their side.

OSS-Fuzz can either run the fuzz targets directly using go test -fuzz=FuzzTargetName, or they can build the binary using go test -c and execute it that way.

From the Go side, fuzzing will need to support the following features which are not currently supported:

  • #49290
  • Fuzzing metrics, including the maximum number of seconds it takes to execute the slowest input during fuzzing and the maximum memory used during fuzzing, which are not currently implemented. We need to figure out how these metrics are shared with OSS-Fuzz.

Conclusion

It's going to be difficult to make a decision right now. We need to do more investigation into what would be involved from the OSS-Fuzz side, and outline the changes would need to be made in the standard library for each option. For example, there is still ambiguity around how native fuzzing could be run in a -libfuzzer mode (e.g. how is the seed corpus provided?).

My inclination is towards (2), as it will provide product parity between running fuzz targets locally, and continuously with OSS-Fuzz. But we'll see.

/cc @golang/fuzzing

@naveensrinivasan
Copy link

@naveensrinivasan naveensrinivasan commented Dec 17, 2021

On option 2, I recently asked the question google/oss-fuzz#7020 and it looks like oss-fuzz is likely to support. cc @inferno-chromium

@inferno-chromium
Copy link

@inferno-chromium inferno-chromium commented Dec 20, 2021

Adalogics and @oliverchang plan to evaluate these options and pick one of them in 2022. See google/oss-fuzz#7020 (comment)

@DavidKorczynski
Copy link

@DavidKorczynski DavidKorczynski commented Jan 5, 2022

We have a working PoC for option 1 here: google/oss-fuzz#7055

@prestonvanloon
Copy link

@prestonvanloon prestonvanloon commented Jan 9, 2022

I'd like to express interest in option 1. It is desirable to run alternative fuzzing engines, i.e. libFuzzer, AFL, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants