Skip to content

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

Closed
@katiehockman

Description

@katiehockman
Contributor

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:

  • cmd/go: support corpus minimization #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

Activity

added
NeedsFixThe path to resolution is known, but the work has not been done.
FeatureRequestIssues asking for a new feature that does not need a proposal.
fuzzIssues related to native fuzzing support
on Dec 15, 2021
added this to the Go1.19 milestone on Dec 15, 2021
naveensrinivasan

naveensrinivasan commented on Dec 17, 2021

@naveensrinivasan

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

inferno-chromium commented on Dec 20, 2021

@inferno-chromium

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

DavidKorczynski

DavidKorczynski commented on Jan 5, 2022

@DavidKorczynski

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

prestonvanloon

prestonvanloon commented on Jan 9, 2022

@prestonvanloon

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

ianlancetaylor

ianlancetaylor commented on Jun 24, 2022

@ianlancetaylor
Contributor

CC @fuzz

Looks like this didn't make 1.19. Moving to Backlog. Please recategorize as appropriate. Thanks.

removed this from the Go1.19 milestone on Jun 24, 2022

16 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FeatureRequestIssues asking for a new feature that does not need a proposal.FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.fuzzIssues related to native fuzzing support

    Type

    No type

    Projects

    Status

    Done

    Status

    Done

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @naveensrinivasan@DavidKorczynski@firelizzard18@ianlancetaylor@rolandshoemaker

        Issue actions

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