Add support for .options files to fuzzing_binary

[fmeum]

.options files can be used to supply custom options to sanitizers. While
they are rarely used for C++ fuzz targets (and thus not exposed via the
cc_fuzz_test macro for now), they are necessary to run JVM fuzz targets
correctly and will be used internally by the java_fuzz_test macro in a
follow-up commit.

This generalizes parts of #146.

[fmeum]

If we expose this functionality through the {cc, java}_fuzz_test macro, this could resolve #104. @stefanbucur What do you think?

[stefanbucur]

If we expose this functionality through the {cc, java}_fuzz_test macro, this could resolve #104. @stefanbucur What do you think?

I would like to understand a bit what design alternatives we have here. If I remember correctly, one idea behind #104 was to automatically generate the .options file for OSS-Fuzz from cc_fuzz_test() attributes. This way, developers don't need to maintain one more file with its own file format.

Can we do the same here? What does the developer need to provide in an .options file for Java fuzz targets?

[fmeum]

For Java targets the developer will most likely never need to supply their own .options file. Rather, the file would collect all or at least most of the ASAN_OPTIONS that were previously added to the shell wrapper conditionally here.

I believe the official guidance on length restrictions for C++ fuzz tests is to prefix them withif (Size > 4096) return; style checks rather than use the libFuzzer-dependent max_len, which is otherwise the most obvious candidate for options to me. Do you have some particular options for cc_fuzz_test targets in mind? If so, we could start with exposing just those (and not exposing any options for java_fuzz_test for now)?

[stefanbucur]

Meta-comment: This week I've been away and my replies are slower. Sorry for falling behind with code reviews.

[stefanbucur]

For Java targets the developer will most likely never need to supply their own .options file. Rather, the file would collect all or at least most of the ASAN_OPTIONS that were previously added to the shell wrapper conditionally here.

Ah, I see. How will the ASAN options be passed in that file? I've only seen so far libFuzzer flags, but not ASAN environment options.

I believe the official guidance on length restrictions for C++ fuzz tests is to prefix them withif (Size > 4096) return; style checks rather than use the libFuzzer-dependent max_len, which is otherwise the most obvious candidate for options to me. Do you have some particular options for cc_fuzz_test targets in mind? If so, we could start with exposing just those (and not exposing any options for java_fuzz_test for now)?

Yeah, I can't think of particular C++ options needed at this point (and I agree with you on the max_len use case).

[fmeum]

Ah, I see. How will the ASAN options be passed in that file? I've only seen so far libFuzzer flags, but not ASAN environment options.

The java-example project currently uses a mix of ASan options passed via the environment variable and a .options file (purely for historical reasons). These are in fact interchangeable (except that the .options file does not support bash variable expansion): https://github.com/CodeIntelligenceTesting/oss-fuzz/blob/a9fe789db7b3535869285fbd78f329d81612eb30/infra/base-images/base-runner/run_fuzzer#L80.

[stefanbucur]

Meta-comment: This week I've been away and my replies are slower. Sorry for falling behind with code reviews.

Thanks a lot for your patience with these reviews - I'm now back and will go through these as soon as possible.

[fmeum]

I pushed a new commit to address your comments.