aboutsummaryrefslogtreecommitdiff
path: root/scripts/oss-fuzz
AgeCommit message (Collapse)AuthorFilesLines
2023-02-02gitlab: add lsan suppression file to workaround tcmalloc issuesAlex Bennée1-0/+2
The up-coming upgrade to Fedora 37 will bring in libtcmalloc as a dependency of libglusterfs which confuses our fuzz run. Rather than disable the build lets use LSAN's suppression mechanism to prevent the job from failing. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20230124180127.1881110-10-alex.bennee@linaro.org>
2022-07-22oss-fuzz: ensure base_copy is a generic-fuzzerAlexander Bulekov1-1/+1
Depending on how the target list is sorted in by qemu, the first target (used as the base copy of the fuzzer, to which all others are linked) might not be a generic-fuzzer. Since we are trying to only use generic-fuzz, on oss-fuzz, fix that, to ensure the base copy is a generic-fuzzer. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20220720180946.2264253-1-alxndr@bu.edu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-07-22oss-fuzz: remove binaries from qemu-bundle treePaolo Bonzini1-1/+3
oss-fuzz is finding possible fuzzing targets even under qemu-bundle/.../bin, but they cannot be used because the required shared libraries are missing. Since the fuzzing targets are already placed manually in $OUT, the bindir and libexecdir subtrees are not needed; remove them. Cc: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-07-13datadir: Use bundle mechanismAkihiko Odaki1-4/+4
softmmu/datadir.c had its own implementation to find files in the build tree, but now bundle mechanism provides the unified implementation which works for datadir and the other files. Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-Id: <20220624145039.49929-4-akihiko.odaki@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-07-08fuzz: only use generic-fuzz targets on oss-fuzzAlexander Bulekov1-2/+2
The non-generic-fuzz targets often time-out, or run out of memory. Additionally, they create unreproducible bug-reports. It is possible that this is resulting in failing coverage-reports on OSS-Fuzz. In the future, these test-cases should be fixed, or removed. Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20220623125505.2137534-1-alxndr@bu.edu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-03tests: move libqtest.h back under qtest/Marc-André Lureau1-1/+1
Since commit a2ce7dbd917 ("meson: convert tests/qtest to meson"), libqtest.h is under libqos/ directory, while libqtest.c is still in qtest/. Move back to its original location to avoid mixing with libqos/. Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
2021-09-01fuzz: add an instrumentation filterAlexander Bulekov1-0/+15
By default, -fsanitize=fuzzer instruments all code with coverage information. However, this means that libfuzzer will track coverage over hundreds of source files that are unrelated to virtual-devices. This means that libfuzzer will optimize inputs for coverage observed in timer code, memory APIs etc. This slows down the fuzzer and stores many inputs that are not relevant to the actual virtual-devices. With this change, clang versions that support the "-fsanitize-coverage-allowlist" will only instrument a subset of the compiled code, that is directly related to virtual-devices. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
2021-08-11fuzz: avoid building twice, when running on gitlabAlexander Bulekov1-11/+13
On oss-fuzz, we build twice, to put together a build that is portable to the runner containers. On gitlab ci, this is wasteful and contributes to timeouts on the build-oss-fuzz job. Avoid building twice on gitlab, at the remote cost of potentially missing some cases that break oss-fuzz builds. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20210809111621.54454-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-05scripts/oss-fuzz: Fix typo in documentationPhilippe Mathieu-Daudé1-1/+1
While we only use stdin, the chardev is named 'stdio'. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20210602170759.2500248-4-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-16fuzz: add a script to build reproducersAlexander Bulekov1-0/+160
Currently, bash and C crash reproducers are be built manually. This is a problem, as we want to integrate reproducers into the tree, for regression testing. This patch adds a script that converts a sequence of QTest commands into a pasteable Bash reproducer, or a libqtest-based C program. This will try to wrap pasteable reproducers to 72 chars, but the generated C code will not have nice formatting. Therefore, the C output of this script should be piped through an auto-formatter, such as clang-format Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-02-08fuzz: fix wrong index in clear_bitsQiuhao Li1-1/+1
Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Message-Id: <SYCPR01MB3502E9F6EB06DEDCD484F738FCBA9@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-01-11fuzz: heuristic split write based on past IOsQiuhao Li1-0/+56
If previous write commands write the same length of data with the same step, we view it as a hint. Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <SYCPR01MB3502480AD07811A6A49B8FEAFCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-01-11fuzz: add minimization optionsQiuhao Li1-4/+26
-M1: remove IO commands iteratively -M2: try setting bits in operand of write/out to zero Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <SYCPR01MB350204C52E7A39E6B0EEC870FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-01-11fuzz: set bits in operand of write/out to zeroQiuhao Li1-0/+39
Simplifying the crash cases by opportunistically setting bits in operands of out/write to zero may help to debug, since usually bit one means turn on or trigger a function while zero is the default turn-off setting. Tested bug https://bugs.launchpad.net/qemu/+bug/1908062 Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <SYCPR01MB3502C84B6346A3E3DE708C7BFCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-01-11fuzz: remove IO commands iterativelyQiuhao Li1-15/+26
Now we use a one-time scan and remove strategy in the minimizer, which is not suitable for timing dependent instructions. For example, instruction A will indicate an address where the config chunk locates, and instruction B will make the configuration active. If we have the following instruction sequence: ... A1 B1 A2 B2 ... A2 and B2 are the actual instructions that trigger the bug. If we scan from top to bottom, after we remove A1, the behavior of B1 might be unknowable, including not to crash the program. But we will successfully remove B1 later cause A2 and B2 will crash the process anyway: ... A1 A2 B2 ... Now one more trimming will remove A1. In the perfect case, we would need to be able to remove A and B (or C!) at the same time. But for now, let's just add a loop around the minimizer. Since we only remove instructions, this iterative algorithm is converging. Tested with Bug 1908062. Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <SYCPR01MB350263004448040ACCB9A9F1FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-01-11fuzz: split write operand using binary approachQiuhao Li1-9/+20
Currently, we split the write commands' data from the middle. If it does not work, try to move the pivot left by one byte and retry until there is no space. But, this method has two flaws: 1. It may fail to trim all unnecessary bytes on the right side. For example, there is an IO write command: write addr uuxxxxuu u is the unnecessary byte for the crash. Unlike ram write commands, in most case, a split IO write won't trigger the same crash, So if we split from the middle, we will get: write addr uu (will be removed in next round) write addr xxxxuu For xxxxuu, since split it from the middle and retry to the leftmost byte won't get the same crash, we will be stopped from removing the last two bytes. 2. The algorithm complexity is O(n) since we move the pivot byte by byte. To solve the first issue, we can try a symmetrical position on the right if we fail on the left. As for the second issue, instead moving by one byte, we can approach the boundary exponentially, achieving O(log(n)). Give an example: xxxxuu len=6 + | + xxx,xuu 6/2=3 fail + +--------------+-------------+ | | + + xx,xxuu 6/2^2=1 fail xxxxu,u 6-1=5 success + + +------------------+----+ | | | +-------------+ u removed + + xx,xxu 5/2=2 fail xxxx,u 6-2=4 success + | +-----------+ u removed In some rare cases, this algorithm will fail to trim all unnecessary bytes: xxxxxxxxxuxxxxxx xxxxxxxx-xuxxxxxx Fail xxxx-xxxxxuxxxxxx Fail xxxxxxxxxuxx-xxxx Fail ... I think the trade-off is worth it. Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <SYCPR01MB3502D26F1BEB680CBBC169E5FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-01-11fuzz: double the IOs to remove for every loopQiuhao Li1-12/+21
Instead of removing IO instructions one by one, we can try deleting multiple instructions at once. According to the locality of reference, we double the number of instructions to remove for the next round and recover it to one once we fail. This patch is usually significant for large input. Test with quadrupled trace input at: https://bugs.launchpad.net/qemu/+bug/1890333/comments/1 Patched 1/6 version: real 0m45.904s user 0m16.874s sys 0m10.042s Refined version: real 0m11.412s user 0m6.888s sys 0m3.325s Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <SYCPR01MB350280A67BB55C3FADF173E3FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-01-11fuzz: accelerate non-crash detectionQiuhao Li1-13/+31
We spend much time waiting for the timeout program during the minimization process until it passes a time limit. This patch hacks the CLOSED (indicates the redirection file closed) notification in QTest's output if it doesn't crash. Test with quadrupled trace input at: https://bugs.launchpad.net/qemu/+bug/1890333/comments/1 Original version: real 1m37.246s user 0m13.069s sys 0m8.399s Refined version: real 0m45.904s user 0m16.874s sys 0m10.042s Note: Sometimes the mutated or the same trace may trigger a different crash summary (second-to-last line) but indicates the same bug. For example, Bug 1910826 [1], which will trigger a stack overflow, may output summaries like: SUMMARY: AddressSanitizer: stack-overflow /home/qiuhao/hack/qemu/build/../softmmu/physmem.c:488 in flatview_do_translate or SUMMARY: AddressSanitizer: stack-overflow (/home/qiuhao/hack/qemu/build/qemu-system-i386+0x27ca049) in __asan_memcpy Etc. If we use the whole summary line as the token, we may be prevented from further minimization. So in this patch, we only use the first three words which indicate the type of crash: SUMMARY: AddressSanitizer: stack-overflow [1] https://bugs.launchpad.net/qemu/+bug/1910826 Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <SYCPR01MB350251DC04003450348FAF68FCAB0@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-11-10scripts/oss-fuzz: give all fuzzers -target namesAlexander Bulekov1-6/+6
We switched to hardlinks in a942f64cc4 ("scripts/oss-fuzz: use hardlinks instead of copying") The motivation was to conserve space (50 fuzzers built with ASAN, can weigh close to 9 GB). Unfortunately, OSS-Fuzz (partially) treated the underlying copy of the fuzzer as a standalone fuzzer. To attempt to fix, we tried: f8b8f37463 ("scripts/oss-fuzz: rename bin/qemu-fuzz-i386") This was also not a complete fix, because though OSS-Fuzz ignores the renamed fuzzer, the underlying ClusterFuzz, doesn't: https://storage.googleapis.com/clusterfuzz-builds/qemu/targets.list.address https://oss-fuzz-build-logs.storage.googleapis.com/log-9bfb55f9-1c20-4aa6-a49c-ede12864eeb2.txt (clusterfuzz still lists qemu-fuzz-i386.base as a fuzzer) This change keeps the hard-links, but makes them all point to a file with a qemu-fuzz-i386-target-.. name. If we have targets, A, B, C, the result will be: qemu-fuzz-i386-target-A (base file) qemu-fuzz-i386-target-B -> qemu-fuzz-i386-target-A qemu-fuzz-i386-target-C -> qemu-fuzz-i386-target-A The result should be that every file that looks like a fuzzer to OSS-Fuzz/ClusterFuzz, can run as a fuzzer (we don't have a separate base copy). Unfortunately, there is not simple way to test this locally. In the future, it might be worth it to link the majority of QEMU in as a shared-object (see https://github.com/google/oss-fuzz/issues/4575 ) Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201108171136.160607-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-11-03scripts/oss-fuzz: rename bin/qemu-fuzz-i386Alexander Bulekov1-2/+2
OSS-Fuzz changed the way it scans for fuzzers in $DEST_DIR. The new code also scans subdirectories for fuzzers. This means that OSS-Fuzz is considering bin/qemu-fuzz-i386 as an independent fuzzer (it is not - it requires a --fuzz-target argument). This has led to coverage-build failures and false crash reports. To work around this, we take advantage of OSS-Fuzz' filename extension check - OSS-Fuzz will not run anything that has an extension that is not ".exe": https://github.com/google/oss-fuzz/blob/master/infra/utils.py#L115 Reported-by: OSS-Fuzz (Issue 26725) Reported-by: OSS-Fuzz (Issue 26679) Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201101212245.185819-1-alxndr@bu.edu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-10-26scripts/oss-fuzz: ignore the generic-fuzz targetAlexander Bulekov1-2/+8
generic-fuzz is not a standalone fuzzer - it requires some env variables to be set. On oss-fuzz, we set these with some predefined generic-fuzz-{...} targets, that are thin wrappers around generic-fuzz. Do not make a link for the generic-fuzz from the oss-fuzz build, so oss-fuzz does not treat it as a standalone fuzzer. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201023150746.107063-18-alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> [thuth: Reformatted one comment to stay within the 80 columns limit] Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-26scripts/oss-fuzz: use hardlinks instead of copyingAlexander Bulekov1-1/+7
Prior to this, fuzzers in the output oss-fuzz directory were exactly the same executable, with a different name to do argv[0]-based fuzz-target selection. This is a waste of space, especially since these binaries can weigh many MB. Instead of copying, use hard links, to cut down on wasted space. We need to place the primary copy of the executable into DEST_DIR, since this is a separate file-system on oss-fuzz. We should not place it directly into $DEST_DIR, since oss-fuzz will treat it as an independent fuzzer and try to run it for fuzzing. Instead, we create a DEST_DIR/bin directory to store the primary copy. Suggested-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201023150746.107063-17-alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-26scripts/oss-fuzz: Add crash trace minimization scriptAlexander Bulekov1-0/+157
Once we find a crash, we can convert it into a QTest trace. Usually this trace will contain many operations that are unneeded to reproduce the crash. This script tries to minimize the crashing trace, by removing operations and trimming QTest bufwrite(write addr len data...) commands. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20201023150746.107063-12-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-26scripts/oss-fuzz: Add script to reorder a generic-fuzzer traceAlexander Bulekov1-0/+103
The generic-fuzzer uses hooks to fulfill DMA requests just-in-time. This means that if we try to use QTEST_LOG=1 to build a reproducer, the DMA writes will be logged _after_ the in/out/read/write that triggered the DMA read. To work work around this, the generic-fuzzer annotates these just-in time DMA fulfilments with a tag that we can use to discern them. This script simply iterates over a raw qtest trace (including log messages, errors, timestamps etc), filters it and re-orders it so that DMA fulfillments are placed directly _before_ the qtest command that will cause the DMA access. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20201023150746.107063-11-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-09-17scripts/: fix some comment spelling errorszhaolichang1-1/+1
I found that there are many spelling errors in the comments of qemu, so I used the spellcheck tool to check the spelling errors and finally found some spelling errors in the scripts folder. Signed-off-by: zhaolichang <zhaolichang@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200917075029.313-5-zhaolichang@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-09-08oss-fuzz: fix rpathAlexander Bulekov1-1/+1
Prior to this change, readelf -d build/out/qemu/qemu-fuzz-i386-target-virtio-net-slirp ... 0x000000000000000f (RPATH) Library rpath: ['$$ORIGIN/lib':$ORIGIN/migration:$ORIGIN/] As of 1a4db552d8 ("ninjatool: quote dollars in variables"), we don't need to manually double the dollars. Also, remove the single-quotes as they are copied into the rpath. After this change: 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib:$ORIGIN/migration:$ORIGIN/] Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20200902142657.112879-3-alxndr@bu.edu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-21meson: link emulators without Makefile.targetPaolo Bonzini1-9/+11
The binaries move to the root directory, e.g. qemu-system-i386 or qemu-arm. This requires changes to qtests, CI, etc. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-21oss-fuzz/build: remove LIB_FUZZING_ENGINEPaolo Bonzini1-11/+5
Meson build scripts will only include qemu-fuzz-TARGET rules if configured with --enable-fuzzing, and that takes care of adding -fsanitize=fuzzer. Therefore we can just specify the configure option and stop modifying the CFLAGS and CONFIG_FUZZ options in the "make" invocation. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-21scripts/oss-fuzz: Limit target list to i386-softmmuThomas Huth1-1/+1
The build.sh script only copies qemu-fuzz-i386 to the destination folder, so we can speed up the compilation step quite a bit by not compiling the other targets here. Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-06-15fuzz: add oss-fuzz build-scriptAlexander Bulekov1-0/+105
It is neater to keep this in the QEMU repo, since any change that requires an update to the oss-fuzz build configuration, can make the necessary changes in the same series. Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20200612055145.12101-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
generated by cgit v1.1 at 2024-11-16 23:37:03 +0000