Commit Graph

53 Commits

Author SHA1 Message Date
Shao-Ce SUN 0c660256eb [NFC] Trim trailing whitespace in *.rst 2021-11-15 09:17:08 +08:00
Kostya Serebryany b7f3a4f4fa [sancov] add tracing for loads and store
add tracing for loads and stores.

The primary goal is to have more options for data-flow-guided fuzzing,
i.e. use data flow insights to perform better mutations or more agressive corpus expansion.
But the feature is general puspose, could be used for other things too.

Pipe the flag though clang and clang driver, same as for the other SanitizerCoverage flags.
While at it, change some plain arrays into std::array.

Tests: clang flags test, LLVM IR test, compiler-rt executable test.

Reviewed By: morehouse

Differential Revision: https://reviews.llvm.org/D113447
2021-11-09 14:35:13 -08:00
Fangrui Song 285dd08b56 [Driver] Delete -fsanitize-coverage-blocklist= in favor of -fsanitize-coverage-ignorelist=
We are settled with -fsanitize-coverage-ignorelist (D101832).
Just delete -fsanitize-coverage-blocklist which is also new.
2021-06-15 20:32:24 -07:00
Marco Elver 4fbc66cd6d [Clang] Enable __has_feature(coverage_sanitizer)
Like other sanitizers, enable __has_feature(coverage_sanitizer) if clang
has enabled at least one SanitizerCoverage instrumentation type.

Because coverage instrumentation selection is not handled via normal
-fsanitize= (and thus not in SanitizeSet), passing this information
through to LangOptions required propagating the already parsed
-fsanitize-coverage= options from CodeGenOptions through to LangOptions
in FixupInvocation().

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D103159
2021-05-27 18:24:21 +02:00
Marco Elver 280333021e [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute
We really ought to support no_sanitize("coverage") in line with other
sanitizers. This came up again in discussions on the Linux-kernel
mailing lists, because we currently do workarounds using objtool to
remove coverage instrumentation. Since that support is only on x86, to
continue support coverage instrumentation on other architectures, we
must support selectively disabling coverage instrumentation via function
attributes.

Unfortunately, for SanitizeCoverage, it has not been implemented as a
sanitizer via fsanitize= and associated options in Sanitizers.def, but
rolls its own option fsanitize-coverage. This meant that we never got
"automatic" no_sanitize attribute support.

Implement no_sanitize attribute support by special-casing the string
"coverage" in the NoSanitizeAttr implementation. To keep the feature as
unintrusive to existing IR generation as possible, define a new negative
function attribute NoSanitizeCoverage to propagate the information
through to the instrumentation pass.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=49035

Reviewed By: vitalybuka, morehouse

Differential Revision: https://reviews.llvm.org/D102772
2021-05-25 12:57:14 +02:00
Kazu Hirata 31443f8e86 [clang] Fix typos in documentation (NFC) 2021-03-06 15:52:52 -08:00
Fangrui Song 2a4317bfb3 [SanitizeCoverage] Rename -fsanitize-coverage-{white,black}list to -fsanitize-coverage-{allow,block}list
Keep deprecated -fsanitize-coverage-{white,black}list as aliases for compatibility for now.

Reviewed By: echristo

Differential Revision: https://reviews.llvm.org/D82244
2020-06-19 22:22:47 -07:00
Matt Morehouse bef187c750 Implement `-fsanitize-coverage-whitelist` and `-fsanitize-coverage-blacklist` for clang
Summary:
This commit adds two command-line options to clang.
These options let the user decide which functions will receive SanitizerCoverage instrumentation.
This is most useful in the libFuzzer use case, where it enables targeted coverage-guided fuzzing.

Patch by Yannis Juglaret of DGA-MI, Rennes, France

libFuzzer tests its target against an evolving corpus, and relies on SanitizerCoverage instrumentation to collect the code coverage information that drives corpus evolution. Currently, libFuzzer collects such information for all functions of the target under test, and adds to the corpus every mutated sample that finds a new code coverage path in any function of the target. We propose instead to let the user specify which functions' code coverage information is relevant for building the upcoming fuzzing campaign's corpus. To this end, we add two new command line options for clang, enabling targeted coverage-guided fuzzing with libFuzzer. We see targeted coverage guided fuzzing as a simple way to leverage libFuzzer for big targets with thousands of functions or multiple dependencies. We publish this patch as work from DGA-MI of Rennes, France, with proper authorization from the hierarchy.

Targeted coverage-guided fuzzing can accelerate bug finding for two reasons. First, the compiler will avoid costly instrumentation for non-relevant functions, accelerating fuzzer execution for each call to any of these functions. Second, the built fuzzer will produce and use a more accurate corpus, because it will not keep the samples that find new coverage paths in non-relevant functions.

The two new command line options are `-fsanitize-coverage-whitelist` and `-fsanitize-coverage-blacklist`. They accept files in the same format as the existing `-fsanitize-blacklist` option <https://clang.llvm.org/docs/SanitizerSpecialCaseList.html#format>. The new options influence SanitizerCoverage so that it will only instrument a subset of the functions in the target. We explain these options in detail in `clang/docs/SanitizerCoverage.rst`.

Consider now the woff2 fuzzing example from the libFuzzer tutorial <https://github.com/google/fuzzer-test-suite/blob/master/tutorial/libFuzzerTutorial.md>. We are aware that we cannot conclude much from this example because mutating compressed data is generally a bad idea, but let us use it anyway as an illustration for its simplicity. Let us use an empty blacklist together with one of the three following whitelists:

```
  # (a)
  src:*
  fun:*

  # (b)
  src:SRC/*
  fun:*

  # (c)
  src:SRC/src/woff2_dec.cc
  fun:*
```

Running the built fuzzers shows how many instrumentation points the compiler adds, the fuzzer will output //XXX PCs//. Whitelist (a) is the instrument-everything whitelist, it produces 11912 instrumentation points. Whitelist (b) focuses coverage to instrument woff2 source code only, ignoring the dependency code for brotli (de)compression; it produces 3984 instrumented instrumentation points. Whitelist (c) focuses coverage to only instrument functions in the main file that deals with WOFF2 to TTF conversion, resulting in 1056 instrumentation points.

For experimentation purposes, we ran each fuzzer approximately 100 times, single process, with the initial corpus provided in the tutorial. We let the fuzzer run until it either found the heap buffer overflow or went out of memory. On this simple example, whitelists (b) and (c) found the heap buffer overflow more reliably and 5x faster than whitelist (a). The average execution times when finding the heap buffer overflow were as follows: (a) 904 s, (b) 156 s, and (c) 176 s.

We explain these results by the fact that WOFF2 to TTF conversion calls the brotli decompression algorithm's functions, which are mostly irrelevant for finding bugs in WOFF2 font reconstruction but nevertheless instrumented and used by whitelist (a) to guide fuzzing. This results in longer execution time for these functions and a partially irrelevant corpus. Contrary to whitelist (a), whitelists (b) and (c) will execute brotli-related functions without instrumentation overhead, and ignore new code paths found in them. This results in faster bug finding for WOFF2 font reconstruction.

The results for whitelist (b) are similar to the ones for whitelist (c). Indeed, WOFF2 to TTF conversion calls functions that are mostly located in SRC/src/woff2_dec.cc. The 2892 extra instrumentation points allowed by whitelist (b) do not tamper with bug finding, even though they are mostly irrelevant, simply because most of these functions do not get called. We get a slightly faster average time for bug finding with whitelist (b), which might indicate that some of the extra instrumentation points are actually relevant, or might just be random noise.

Reviewers: kcc, morehouse, vitalybuka

Reviewed By: morehouse, vitalybuka

Subscribers: pratyai, vitalybuka, eternalsakura, xwlin222, dende, srhines, kubamracek, #sanitizers, lebedev.ri, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D63616
2020-04-10 10:44:03 -07:00
Pratyai Mazumder ced398fdc8 [SanitizerCoverage] Add -fsanitize-coverage=inline-bool-flag
Reviewers: kcc, vitalybuka

Reviewed By: vitalybuka

Subscribers: cfe-commits, llvm-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D77637
2020-04-09 02:40:55 -07:00
Nico Weber 46be168977 fix doc typos to cycle bots 2020-01-19 09:51:25 -05:00
Max Moroz 123883807d Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.
Summary:
There is a bug for this: https://bugs.llvm.org/show_bug.cgi?id=34636
But it would be also helpful to leave a note in the docs to prevent users from
running into issues, e.g. https://crbug.com/926588.

Reviewers: morehouse

Reviewed By: morehouse

Subscribers: cfe-commits, llvm-commits, kcc

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57474

llvm-svn: 352890
2019-02-01 17:12:35 +00:00
Kostya Serebryany a78a44d480 [sanitizer-coverage] prune trace-cmp instrumentation for CMP isntructions that feed into the backedge branch. Instrumenting these CMP instructions is almost always useless (and harmful) for fuzzing
llvm-svn: 352818
2019-01-31 23:43:00 +00:00
Eugene Zelenko adcb3f520b [Documentation] Use HTTPS whenever possible
Differential revision: https://reviews.llvm.org/D56946

llvm-svn: 351976
2019-01-23 20:39:07 +00:00
Sylvestre Ledru bc5c3f5727 Update our URLs in clang doc to use https
llvm-svn: 346101
2018-11-04 17:02:00 +00:00
Dmitry Vyukov 7097b4d22d docs: don't say that data flow tracing interface is unstable
We are starting to use data flow tracing in kernel.
The interface is not subject to change anymore.

Reviewed in https://reviews.llvm.org/D37303

llvm-svn: 312232
2017-08-31 11:02:44 +00:00
Kostya Serebryany d3e4b7e24a [sanitizer-coverage] extend fsanitize-coverage=pc-table with flags for every PC
llvm-svn: 311794
2017-08-25 19:29:47 +00:00
Kostya Serebryany a38bbe30eb [sanitizer-coverage] document -fsanitize-coverage=pc-table and -fsanitize-coverage=inline-8bit-counters
llvm-svn: 311719
2017-08-24 22:40:03 +00:00
Alexander Potapenko 5241081532 [sanitizer-coverage] Change cmp instrumentation to distinguish const operands
This implementation of SanitizerCoverage instrumentation inserts different
callbacks depending on constantness of operands:

  1. If both operands are non-const, then a usual
     __sanitizer_cov_trace_cmp[1248] call is inserted.
  2. If exactly one operand is const, then a
     __sanitizer_cov_trace_const_cmp[1248] call is inserted. The first
     argument of the call is always the constant one.
  3. If both operands are const, then no callback is inserted.

This separation comes useful in fuzzing when tasks like "find one operand
of the comparison in input arguments and replace it with the other one"
have to be done. The new instrumentation allows us to not waste time on
searching the constant operands in the input.

Patch by Victor Chibotaru.

llvm-svn: 310600
2017-08-10 15:00:13 +00:00
Kostya Serebryany 50fb618b93 [sanitizer-coverage] implement -fsanitize-coverage=no-prune,... instead of a hidden -mllvm flag. clang part.
llvm-svn: 302320
2017-05-05 23:28:18 +00:00
Kostya Serebryany 2a451c504f [sanitizer-coverage] update the SanitizerCoverage docs to reflect the current state
llvm-svn: 301888
2017-05-02 00:32:57 +00:00
Kostya Serebryany 4a27c79a95 [sanitizer-coverage] add a deprecation note to coverage_direct=1
llvm-svn: 301824
2017-05-01 19:52:01 +00:00
Kostya Serebryany a1ef90ab9c [sanitizer-coverage] trim down the docs
llvm-svn: 300776
2017-04-19 22:25:30 +00:00
Kostya Serebryany 9d1ed13b53 [sanitizer-coverage] deprecate some of the stale coverage variants
llvm-svn: 300738
2017-04-19 19:57:16 +00:00
Mike Aizatsky 9afa12bbc5 [sancov] pc_guard_init is called at least once per DSO.
Summary: Documentation update for https://reviews.llvm.org/D29662

Differential Revision: https://reviews.llvm.org/D29722

llvm-svn: 294522
2017-02-08 21:28:39 +00:00
Kostya Serebryany 4b2ff07c11 [sanitizer-coverage] emit __sanitizer_cov_trace_pc_guard w/o a preceding 'if' by default. Update the docs, also add deprecation notes around other parts of sanitizer coverage
llvm-svn: 292862
2017-01-24 00:57:31 +00:00
Mike Aizatsky a271d1a531 [sancov] documentation update after r283241
llvm-svn: 283242
2016-10-04 19:19:16 +00:00
Kostya Serebryany f74169c9d6 [sanitizer-coverage] fix docs
llvm-svn: 282962
2016-09-30 21:57:10 +00:00
Mike Aizatsky a675e0e03c [sancov] -symbolize documentation update
llvm-svn: 282948
2016-09-30 21:02:56 +00:00
Kostya Serebryany 851cb98269 [sanitizer-coverage] a bit more docs
llvm-svn: 282752
2016-09-29 19:06:09 +00:00
Kostya Serebryany d6ae22a7ab [sanitizer-coverage] more docs
llvm-svn: 282751
2016-09-29 18:58:17 +00:00
Kostya Serebryany 6bb5498a4a [sanitize-coverage] doc typo
llvm-svn: 282749
2016-09-29 18:34:40 +00:00
Kostya Serebryany a9b0dd0e51 [sanitizer-coverage/libFuzzer] make the guards for trace-pc 32-bit; create one array of guards per function, instead of one guard per BB. reorganize the code so that trace-pc-guard does not create unneeded globals
llvm-svn: 282735
2016-09-29 17:43:24 +00:00
Kostya Serebryany 8e781a888a [libFuzzer] use 'if guard' instead of 'if guard >= 0' with trace-pc; change the guard type to intptr_t; use separate array for 8-bit counters
llvm-svn: 281845
2016-09-18 04:52:23 +00:00
Kostya Serebryany 8ad4155745 [sanitizer-coverage] change trace-pc to use 8-byte guards
llvm-svn: 281809
2016-09-17 05:03:05 +00:00
Kostya Serebryany 66a9c175bf [sanitizer-coverage] make trace-pc-guard and indirect-call work together
llvm-svn: 281665
2016-09-15 22:11:08 +00:00
Kostya Serebryany 60cdd6113f [sanitizer-coverage] add yet another flavour of coverage instrumentation: trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this one. Clang part
llvm-svn: 281432
2016-09-14 01:39:49 +00:00
Kostya Serebryany 3b41971763 [sanitizer-coverage] add two more modes of instrumentation: trace-div and trace-gep, mostly usaful for value-profile-based fuzzing; clang part
llvm-svn: 280044
2016-08-30 01:27:03 +00:00
Kostya Serebryany 070bcb0d68 [sanitizer-coverag] update the docs in __sanitizer_cov_trace_cmp
llvm-svn: 279028
2016-08-18 01:26:36 +00:00
Evgeniy Stepanov 5b49eb42c5 [sanitizer] Allow sanitize coverage w/o sanitizers.
The reason is that this (a) seems to work just fine and (b) useful when building stuff with
sanitizer+coverage, but need to exclude the sanitizer for a particular source file.

llvm-svn: 272717
2016-06-14 21:33:40 +00:00
Kostya Serebryany 6453786b26 [sanitizer-coverage] better docs for -fsanitize-coverage=trace-bb
llvm-svn: 266672
2016-04-18 21:28:37 +00:00
Aaron Ballman 0f6f82a3a8 Use an anonymous hyperlink reference to eliminate Sphinx warnings.
llvm-svn: 261523
2016-02-22 13:09:36 +00:00
Kostya Serebryany 52e86493e3 [sanitizer-coverage] allow -fsanitize-coverage=trace-pc w/o any other sanitizer and w/o ...=[func,bb,edge]. This makes this syntax a superset of the GCC's syntax
llvm-svn: 261182
2016-02-18 00:49:23 +00:00
Kostya Serebryany d4590c7304 [sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar to trace-bb, but has a different API. We already use the equivalent flag in GCC for Linux kernel fuzzing. We may be able to use this flag with AFL too
llvm-svn: 261159
2016-02-17 21:34:43 +00:00
Sylvestre Ledru be8f396bde Fix some typos in the clang doc
llvm-svn: 260856
2016-02-14 20:20:58 +00:00
Mike Aizatsky a731ee3a80 [sancov] improved object files handling.
Documentation change for: http://reviews.llvm.org/D17169

Differential Revision: http://reviews.llvm.org/D17175

llvm-svn: 260630
2016-02-12 00:29:45 +00:00
Mike Aizatsky 3828cbbf9f [sancov] sancov tool documentation
Differential Revision: http://reviews.llvm.org/D16432

llvm-svn: 259000
2016-01-27 23:56:12 +00:00
Kostya Serebryany 5ce81794c3 [sanitizer coverage] document -fsanitize-coverage=trace-bb
llvm-svn: 254481
2015-12-02 02:08:26 +00:00
Kostya Serebryany a94e6e7eb0 [libFuzzer] clarify the limitation of fsanitize-coverage=trace-cmp
llvm-svn: 254337
2015-11-30 22:17:19 +00:00
Kostya Serebryany b17e298a64 [libFuzzer] minimal documentation on data-flow-guided fuzzing
llvm-svn: 243793
2015-07-31 21:48:10 +00:00
Alexey Samsonov 8fffba1ef1 Update docs for SanitizerCoverage.
llvm-svn: 236793
2015-05-07 23:04:19 +00:00