Add randomized fuzzer selection to Fuchsia runs.#471
Conversation
|
/gcbrun |
1 similar comment
|
/gcbrun |
oliverchang
left a comment
There was a problem hiding this comment.
Nice! some initial comments
| self.host = Host.from_dir( | ||
| os.path.join(fuchsia_resources_dir, 'build', 'out', 'default')) | ||
| self.device = Device(self.host, 'localhost', fuchsia_portnum) | ||
| pkg, tgt = environment.get_value('FUZZ_TARGET').split('/') |
There was a problem hiding this comment.
s/pkg/package/ and s/tgt/target/
There was a problem hiding this comment.
Also, what's the format of "FUZZ_TARGET" ? I'm assuming package_name/binary_name ?
@inferno-chromium Seems like another case where we need to support / in a fuzz target name. Seems like we need to normalize the binary name too (and not just project).
There was a problem hiding this comment.
Yep, that's the expected format of FUZZ_TARGET.
Completed s/pkg/package/ and s/tgt/target/.
(Leaving comment open--I don't have context on the question of "supporting slashes in target names" but I assume @inferno-chromium may need to peek :) )
| @@ -0,0 +1,13 @@ | |||
| # Copyright 2019 Google LLC | |||
There was a problem hiding this comment.
For discussion:
It seems better to include these scripts with the build, rather than copying them to CF as-is since the Fuchsia SDK is unstable. That way, for each build we should be guaranteed to have a set of scripts that work. This is important for regression task etc where we do bisects.
We're also in the midst of doing PY2->PY3, and copying things here may complicate things. Do these scripts work with PY3 already?
If we go with that, we also can't import the scripts as-is, because importing is fairly permanent and we shouldn't try to reimport if we set up a build for another revision. We may need something like a stable CLI interface here for the necessary functionality.
There was a problem hiding this comment.
Discussed during meeting today.
Consensus seems to be:
-
we're hard-forking these scripts from Fuchsia, feel free to request changes s.t. they meet ClusterFuzz's style guide
-
we agreed that the Fuchsia team will be responsible for validating that "whatever is placed in the build bucket" is run-able via these scripts
-
we accept the risk that, should we need to change/modify these scripts (which we're hoping is rather unlikely!), performing bisects for older builds will become either impossible or require a cumbersome hack
Finally, I think these scripts work with Python 3, but I'm not sure how to test such a thing. Guidance would be very appreciated! :D
There was a problem hiding this comment.
we accept the risk that, should we need to change/modify these scripts (which we're hoping is rather unlikely!), performing bisects for older builds will become either impossible or require a cumbersome hack
We also brought up the idea of having a minimal "input pusher" utility with every build for this purpose, since that's the part that is most likely to change. Did we reach a decision on whether or not to do this? @nopsledder
|
/gcbrun |
Apologies for the length of the CL; I promise it's shorter than it looks (though I can chop it up further). Also apologies for the delay; there was a Fuchsia hack-it week, and some instability/thrashing on the Fuchsia side of things. This PR does the following: * Adds the fuchsia_utils directory, which contains a (hopefully) stable interface for working with Fuchsia. This includes logic for extracting Fuzzers from a Fuchsia build. * Moves the Fuchsia build logic into build_manager. While it's a very tiny class right now, and doesn't take much advantage of build_manager features, this should allow it to e.g. use the weighted random selection in future CLs, handle revision # logic more gracefully, etc. * Adds the ability to *choose* a fuzzer at random, and run it. (Left for a future CL is extracting the crash log from the device and placing it someplace useful, though *writing* the log should be handled automagically by our wrapper class.) My only question is the license headers: I added the standard Google LLC license header to the files we're yoinking from Fuchsia, but *also* left the Fuchsia license header in place. I do not know whether we can just merge these, if there's an elegant way to handle it, etc--I would've just left the files totally intact, but the linter complained about the header not looking right :) So yeah, let me know.
5824cee to
53d482a
Compare
|
/gcbrun |
|
/gcbrun |
oliverchang
left a comment
There was a problem hiding this comment.
nice! sorry for the delay, but here some additional comments.
|
/gcbrun |
|
/gcbrun |
oliverchang
left a comment
There was a problem hiding this comment.
Looking great! Thanks for addressing all the comments.
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
|
Everything seems to work on App Engine, merging. |
Apologies for the length of the CL; I promise it's shorter than it looks
(though I can chop it up further).
Also apologies for the delay; there was a Fuchsia hack-it week, and some
instability/thrashing on the Fuchsia side of things.
This PR does the following:
Adds the fuchsia_utils directory, which contains a (hopefully) stable
interface for working with Fuchsia. This includes logic for extracting
Fuzzers from a Fuchsia build.
Moves the Fuchsia build logic into build_manager. While it's a very
tiny class right now, and doesn't take much advantage of build_manager
features, this should allow it to e.g. use the weighted random selection
in future CLs, handle revision # logic more gracefully, etc.
Adds the ability to choose a fuzzer at random, and run it. (Left
for a future CL is extracting the crash log from the device and placing
it someplace useful, though writing the log should be handled
automagically by our wrapper class.)
My only question is the license headers: I added the standard Google LLC
license header to the files we're yoinking from Fuchsia, but also left
the Fuchsia license header in place. I do not know whether we can just
merge these, if there's an elegant way to handle it, etc--I would've
just left the files totally intact, but the linter complained about the
header not looking right :) So yeah, let me know.