This is an archive of the discontinued LLVM Phabricator instance.

[libfuzzer] arbitrary function adapter
ClosedPublic

Authored by aizatsky on Mar 2 2016, 2:52 PM.

Details

Summary

The adapter automates converting sequence of bytes into arbitrary arguments.

Diff Detail

Repository
rL LLVM

Event Timeline

aizatsky updated this revision to Diff 49672.Mar 2 2016, 2:52 PM
aizatsky retitled this revision from to WIP [libfuzzer] arbitrary function adapter draft.
aizatsky updated this object.
aizatsky updated this revision to Diff 49683.Mar 2 2016, 3:48 PM
  • implemented UnpackAndApply.
aizatsky updated this revision to Diff 49693.Mar 2 2016, 5:28 PM

finished implementation.

aizatsky retitled this revision from WIP [libfuzzer] arbitrary function adapter draft to [libfuzzer] arbitrary function adapter.Mar 2 2016, 5:29 PM
aizatsky updated this object.
aizatsky added reviewers: kcc, eugenis.
aizatsky added a subscriber: llvm-commits.
aizatsky added a reviewer: pcc.Mar 2 2016, 5:35 PM
eugenis edited edge metadata.Mar 3 2016, 11:47 AM

I'm not sure about the whole idea of splitting an array of bytes into multiple arguments. It seems like a lot of mutations in the input byte array would result in very non-local changes to the argument list, ex. inserting a byte at the beginning would shift all arguments to the right which could give them an entirely different meaning.

Would it be better to expose individual arguments to the fuzzing engine?

lib/Fuzzer/FuzzerFnAdapter.h
104 ↗(On Diff #49693)

Space around "<" in "N<std::tuple_size" would greatly help readability.
Did you run this through clang-format?

I'm not sure about the whole idea of splitting an array of bytes into multiple arguments. It seems like a lot of mutations in the input byte array would result in very non-local changes to the argument list, ex. inserting a byte at the beginning would shift all arguments to the right which could give them an entirely different meaning.

Would it be better to expose individual arguments to the fuzzing engine?

I don't think libfuzzer would do something different if it new anything about arguments. Yes, it could shift, but you can look at it as creating an interesting permutation.

lib/Fuzzer/FuzzerFnAdapter.h
104 ↗(On Diff #49693)

Yes, this file is 100% clang-formatted. I'll fix this line manually and try to remember to refix it after format.

This revision was automatically updated to reflect the committed changes.