mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 18:21:39 +01:00
Jan Beulich
6fba45ca3b
Our present approach is working fully behind the compiler's back. This
was found to not work with LTO. Employ ld's --wrap= option instead. Note
that while this makes the build work at least with new enough gcc (it
doesn't with gcc7, for example, due to tool chain side issues afaict),
according to my testing things still won't work when building the
fuzzing harness with afl-cc: While with the gcc7 tool chain I see afl-as
getting invoked, this does not happen with gcc13. Yet without using that
assembler wrapper the resulting binary will look uninstrumented to
afl-fuzz.
While checking the resulting binaries I noticed that we've gained uses
of snprintf() and strstr(), which only just so happen to not cause any
problems. Add a wrappers for them as well.
Since we don't have any actual uses of v{,sn}printf(), no definitions of
their wrappers appear (just yet). But I think we want
__wrap_{,sn}printf() to properly use __real_v{,sn}printf() right away,
which means we need delarations of the latter.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
# OVERVIEW This directory provides fuzzing targets to be run inside Google oss-fuzz infrastructure. See also https://github.com/google/oss-fuzz. # HOW IT WORKS We need to provide the source code and the rune to produce objects or archives (artefacts) from source code. These items ideally should live inside xen.git so that they can be kept up to date. The artefacts contain all the code we wish to fuzz and a function called LLVMFuzzerTestOneInput. LLVMFuzzerTestOneInput is the entry point to the code we wish to fuzz. Note that we don't produce executable programs because we don't have libFuzzEngine locally. libFuzzEngine is maintained by oss-fuzz. We also provide build script to oss-fuzz. The build script will inherit the correct compiler settings and be run in a pre-setup environment, which has libFuzzEngine installed. The build script is responsible for calling the correct Xen build rune to produce the artefacts, then link them against libFuzzEngine to produce executables, which will run in oss-fuzz infrastructure. Please refer to official oss-fuzz documents for the most up-to-date descriptions for all moving parts. # HOW TO IMPROVE THE FUZZING TARGETS Feel free to modify each fuzzing targets at will. Make sure they build by invoking make as you would build tools. To actually test the new code, you would need to run the target in standalone mode, please refer to oss-fuzz documents on how to do that. It is highly recommended that you run the new target for a while to weed out error in plumbing code to avoid false positives.