Add support for additional libfuzzer sanitizers

[puhley]

Currently, the libfuzzer implementation only supports ASAN on Linux instances. In /src/runtime-tools/linux/run.sh, OneFuzz sets the following environment variable to enable ASAN:

export ASAN_SYMBOLIZER_PATH=/onefuzz/bin/llvm-symbolizer

However, it is possible to modify run.sh to support additional sanitizers such as UBSAN, MSAN, and TSAN. An initial proposal would be to add the following environment variables to run.sh:

export UBSAN_SYMBOLIZER_PATH=/onefuzz/bin/llvm-symbolizer
export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1:handle_abort=1
export MSAN_SYMBOLIZER_PATH=/onefuzz/bin/llvm-symbolizer
export TSAN_OPTIONS=external_symbolizer_path=/onefuzz/bin/llvm-symbolizer

By adding these environment variables, libfuzzer could be used with more sanitizers than just ASAN.

A more advanced implementation might be to allow people to specify the environment variables via the command line. However, considering that the environment variables are to specify the location of the llvm-symbolizer, and the location of that binary is controlled by OneFuzz, it seems like it is a better short-term approach to make OneFuzz set these environment variables.

If approved, I can create a pull request with these changes.

AB#35935

[ranweiler]

Note: these should all be expressible right now via the per-task _env template variables (target_env, analyzer_env, supervisor_env, &c). But this PR suggests a much more usable default, which I support, especially due to how error-prone the external symbolizer machinery is (e.g. the specified symbolizer must be exactly named llvm-symbolizer).

My questions:

1. Just because we're currently setting the external symbolizer in run.sh doesn't mean we should be. Maybe these defaults should more properly be part of the onefuzz-agent, or the libraries it uses to spawn processes.
2. Beyond llvm-symbolizer config, is run.sh the right place to set the UBSan options?
3. Do we support the crash logs for all of these sanitizers, currently?

I know we at least have tests for parsing TSan crash logs, but not UBSan. So we'll really want to validate the end-to-end behavior for the additional sanitizers.

[ranweiler]

@puhley, I've split this out into the following issues:

• [ ] #1773 (PR: #1778)
• [ ] #1770 (PR: #1787)
• [ ] #1771
• [ ] #1772

I think the correct place to configure sanitizer env vars is in the library code used to invoke targets. This lives in the input-tester crate and in the input_tester module of the onefuzz utility crate. I've described this in more detail in #1773.

[puhley]

This approach makes sense to me. Should we close this issue and transfer the discussion to the new issues or does this issue remain open until the sub-issues are complete?