Parameterized fuzz targets?

[pitrou]

If you want to fuzz different functions in your codebase that accept different kinds of inputs, you need to create a fuzz target for each function.

The way to do this currently is to compile a separate fuzz target for each function. This works fine when there are only a couple of them.

However, there can be a need to fuzz a non-trivial number of functions. Compiling a dedicated fuzz target for each will balloon build times and disk footprint, especially due to static linking. For example, in Arrow each of our fuzz targets is around 120 MB on disk.

It would be nice to define fuzz targets that point to the same executable, but with different parameters. A simple way of passing parameters would be via dedicated environment variables.

A potential application would be the various Parquet encodings out there.

[DavidKorczynski]

If you want to fuzz different functions in your codebase that accept different kinds of inputs, you need to create a fuzz target for each function.

Not necessarily. You can do:

LLVMFuzzerTestOneInput(data, size) {

  target = data[0];
  switch(target){
    case 0: {
      fuzzer_for_func_1(data, size);
    }
    case 1: {  
      fuzzer_for_func_2(data, size);
  }
  ...
}

There's nothing inherently wrong with the above approach -- the state space will increase but the fuzzer does not really care about this as such.

You can still use corpus by e.g. prepending the seeds in the corpus with 1 byte

[maflcko]

Compiling a dedicated fuzz target for each will balloon build times and disk footprint.

At least the CPU build time can be skipped with a hack (use at your own risk):

oss-fuzz/projects/bitcoin-core/build.sh

Lines 82 to 98 in e2227e3

	# OSS-Fuzz requires a separate and self-contained binary for each fuzz target.
	# To inject the fuzz target name in the finished binary, compile the fuzz
	# executable with a "magic string" as the name of the fuzz target.
	#
	# An alternative to mocking the string in the finished binary would be to
	# replace the string in the source code and re-invoke 'cmake --build'. This is slower,
	# so use the hack.
	export MAGIC_STR="b5813eee2abc9d3358151f298b75a72264ffa119d2f71ae7fefa15c4b70b4bc5b38e87e3107a730f25891ea428b2b4fabe7a84f5bfa73c79e0479e085e4ff157"
	sed -i "s|std::getenv(\"FUZZ\")|\"$MAGIC_STR\"|g" "./src/test/fuzz/fuzz.cpp"
	cmake --build build_fuzz -j$(nproc)
	# Replace the magic string with the actual name of each fuzz target
	for fuzz_target in ${FUZZ_TARGETS[@]}; do
	df --human-readable ./src
	python3 -c "c_str_target=b\"${fuzz_target}\x00\";c_str_magic=b\"$MAGIC_STR\";dat=open('./build_fuzz/bin/fuzz','rb').read();dat=dat.replace(c_str_magic, c_str_target+c_str_magic[len(c_str_target):]);open(\"$OUT/$fuzz_target\",'wb').write(dat)"
	chmod +x "$OUT/$fuzz_target"

As for the storage consumption, I haven't bothered to try if a busybox-style "symlink hack" could work with oss-fuzz, because storage is usually fast and cheap.

[pitrou]

There's nothing inherently wrong with the above approach -- the state space will increase but the fuzzer does not really care about this as such.

Hmm, I see. I had thought about that, but explicit paramerization would obviously be more convenient and maintainable. One concern is that I have to reserve enough bytes at the beginning, so as to easily encode all potential future combinations.

You can still use corpus by e.g. prepending the seeds in the corpus with 1 byte

Good point, then I can steer the fuzzer into the "interesting" parts of the search space.

[pitrou]

At least the CPU build time can be skipped with a hack (use at your own risk):

Thanks the pointer @maflcko . That's a nice harness you have here.

[maflcko]

At least the CPU build time can be skipped with a hack (use at your own risk):

Thanks the pointer @maflcko . That's a nice harness you have here.

Heh, thx. If you want to take it over, I think you only need the FuzzTargets() function (and all code that interacts with it):

auto& FuzzTargets()
{
    static std::map<std::string_view, FuzzTarget> g_fuzz_targets;
    return g_fuzz_targets;
}

Just to clarify what I meant with "use at your own risk": It is going to break fuzz introspector (and other fuzz tools that rely on static analysis). This is obviously because std::map is a run-time structure and static analysis can not resolve the map lookup of the fuzz target name statically.

Looking at https://introspector.oss-fuzz.com/project-profile?project=arrow seems to indicate that the fuzz introspector build is not working anyway right now, so it may work fine for you without breaking anything.