Merge remote-tracking branch 'remotes/a1xndr/tags/fuzz-pull-2021-09-01' into staging

Fuzzing Patches for 2021-09-01

# gpg: Signature made Wed 01 Sep 2021 12:42:00 BST
# gpg: using RS

Merge remote-tracking branch 'remotes/a1xndr/tags/fuzz-pull-2021-09-01' into staging

Fuzzing Patches for 2021-09-01

# gpg: Signature made Wed 01 Sep 2021 12:42:00 BST
# gpg: using RSA key FAD4E2BF871375D6340517C44E661DDE583A964E
# gpg: Good signature from "Alexander Bulekov <alxndr@bu.edu>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: FAD4 E2BF 8713 75D6 3405 17C4 4E66 1DDE 583A 964E

* remotes/a1xndr/tags/fuzz-pull-2021-09-01:
MAINTAINERS: add fuzzing reviewer
MAINTAINERS: Add myself as a reviewer for Device Fuzzing
fuzz: unblock SIGALRM so the timeout works
fuzz: use ITIMER_REAL for timeouts
fuzz: add an instrumentation filter
fuzz: make object-name matching case-insensitive
fuzz: adjust timeout to allow for longer inputs
fuzz: fix sparse memory access in the DMA callback

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

fuzz: add an instrumentation filter

By default, -fsanitize=fuzzer instruments all code with coverage
information. However, this means that libfuzzer will track coverage over
hundreds of source files

fuzz: add an instrumentation filter

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>

show more ...