commit - 82cf00ef1620e00fd9fd024df4350e32e0726442
commit + 6df85a13064a0d2c42be38e060637bb8eb4c0774
blob - /dev/null
blob + 843db368b0b97706eced1d78a700d2ef0a6b9651 (mode 644)
--- /dev/null
+++ Glossary.md
+<!--
+
+-->
+
+# Glossary
+
+### C
+
+Coverage: Some information about the behaviour of the target when it executes a given input. Coverage is usually represented as feature set that the input has triggered in the target.
+
+<strong><a id="Corpus" href="#Corpus">Corpus</a></strong>: (also **test corpus**, or **fuzzing corpus**) (*plural*: corpora) A set of [test inputs](#test-input). In most contexts, it refers to a set of minimal test inputs that generate maximal code coverage.
+
+<strong><a id="Cross-pollination" href="#Cross-pollination">Cross-pollination</a></strong>: The term is taken from botany, where one plant pollinates a plant of another variety. In fuzzing, cross-pollination means using a corpus for one [fuzz target](#fuzz-target) to expand a [corpus](#corpus) for another fuzz target. For example, if there are two libraries that process the same common data format, it is often beneficial to cross-pollinate their respective corpora.
+
+### D
+
+Distillation (creating a distilled corpus): A process of choosing a subset of a larger corpus, such that the subset has the same coverage features as the original corpus.
+
+<strong><a id="Dictionary" href="#Dictionary">Dictionary</a></strong>: A file which specifies interesting tokens for a [fuzz target](#fuzz-target). Most [fuzzing engines](#fuzzing-engine) support dictionaries, and will adjust their mutation strategies to process these tokens together.
+
+### F
+
+<strong><a id="Fuzz_Target" href="#Fuzz_Target">Fuzz Target</a></strong> (also **Target Function**, or **Fuzzing Target Function**, or **Fuzzing Entry Point**): A binary, a library, an API, or rather anything that can consume bytes for input and produce some sort of coverage data as an output. A [libFuzzer](https://llvm.org/docs/LibFuzzer.html)'s target can be a Centipede's target. Read more [here](https://github.com/google/fuzzing/blob/master/docs/good-fuzz-target.md). A [specific signature](http://libfuzzer.info#fuzz-target) is required for OSS-Fuzz. Examples: [openssl](https://github.com/openssl/openssl/blob/master/fuzz/x509.c), [re2](https://github.com/google/re2/blob/master/re2/fuzzing/re2_fuzzer.cc),
+[SQLite](https://www.sqlite.org/src/artifact/ad79e867fb504338).
+
+<strong><a id="Fuzzer" href="#Fuzzer">Fuzzer</a></strong>: The most overloaded term and used in a variety of contexts, which makes it bad. Sometimes, "Fuzzer" is referred to a [fuzz target](#fuzz-target), a [fuzzing engine](#fuzzing-engine), a [mutation engine](#mutation-engine), a [test generator](#test-generator) or
+a [fuzzer build](#fuzzer-build).
+
+<strong><a id="Fuzz_Input" href="#Fuzz_Input">Fuzz Input</a></strong>: A sequence of bytes that can be fed to a target. The input can be an arbitrary bag of bytes, or some structured data, e.g. serialized proto.
+
+<strong><a id="Fuzz_Feature" href="#Fuzz_Feature">Fuzz Feature</a></strong>: A number that represents some unique behavior of the target. E.g. a feature 1234567 may represent the fact that a basic block number 987 in the target has been executed 7 times. When executing an input with the target, the fuzzer collects the features that were observed during execution.
+
+<strong><a id="Fuzz_Feature_Set" href="#Fuzz_Feature_Set">Fuzz Feature Set</a></strong>: A set of features associated with one specific input.
+
+<strong><a id="Fuzzer_build" href="#Fuzzer_build">Fuzzer Build</a></strong>: A build that contains all the fuzz targets for a given project, which is run with a specific fuzzing engine, in a specific build mode (e.g. with enabled/disabled assertions), and optionally combined with a sanitizer. In [OSS-Fuzz](https://google.github.io/oss-fuzz/), it is also known as a [job type](https://google.github.io/oss-fuzz/reference/glossary/#job-type).
+
+<strong><a id="Fuzzing_Engine" href="#Fuzzing_Engine">Fuzzing Engine</a></strong>: A program that produces an infinite stream of inputs for a [fuzz target](#fuzz-target) and orchestrates the execution. Examples: [libFuzzer](http://libfuzzer.info), [AFL](lcamtuf.coredump.cx/afl/), [honggfuzz](https://github.com/google/honggfuzz), etc. See related terms [Mutation Engine](#mutation-engine) and [Test Generator](#test-generator).
+
+### M
+
+<strong><a id="Mutation_Engine" href="#Mutation_Engine">Mutation Engine</a></strong>: A tool that takes a set of testcases as input and creates their mutated versions. It is just a generator and does not feed the mutations to [fuzz target](#fuzz-target). Example: [radamsa](https://github.com/aoh/radamsa) (a generic test mutator).
+
+<strong><a id="Mutator" href="#Mutator">Mutator</a></strong>: A function that takes bytes as input and outputs a small random mutation of the input. See also: [structure-aware fuzzing](https://github.com/google/fuzzing/blob/master/docs/structure-aware-fuzzing.md).
+
+### T
+
+<strong><a id="Test_Generator" href="#Test_Generator">Test Generator</a></strong>: A tool that generates testcases from scratch according to some rules or grammar. Examples: [csmith](https://embed.cs.utah.edu/csmith/) (a test generator for C language), [cross_fuzz](http://lcamtuf.coredump.cx/cross_fuzz/) (a cross-document DOM binding test generator).
+
+<strong><a id="Test_Input" href="#Test_Input">Test Input</a></strong>: A sequence of bytes that is used as input to a [fuzz target](#fuzz-target). Typically, a test input is stored in a separate file.
+
+### R
+
+<strong><a id="Reproducer" href="#Reproducer">Reproducer</a></strong>: (also **Test Case**): A [test input](#test-input) that can be used to reproduce a bug when processed by a fuzz target.
+
+### S
+
+Shard: A file representing a subset of the corpus and another file representing feature sets for that same subset of the corpus.
+
+<strong><a id="Sanitizer" href="#Sanitizer">Sanitizer</a></strong>: A [dynamic testing](https://en.wikipedia.org/wiki/Dynamic_testing) tool that can detect bugs during program execution. Examples: [ASan](http://clang.llvm.org/docs/AddressSanitizer.html), [DFSan](http://clang.llvm.org/docs/DataFlowSanitizer.html), [LSan](http://clang.llvm.org/docs/LeakSanitizer.html), [MSan](http://clang.llvm.org/docs/MemorySanitizer.html), [TSan](http://clang.llvm.org/docs/ThreadSanitizer.html), [UBSan](http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html). See also: https://github.com/google/sanitizers
+
+<strong><a id="Seed_Corpus" href="#Seed_Corpus">Seed Corpus</a></strong>: A small initial [corpus](#corpus) prepared with the intent of providing initial coverage for fuzzing. Rather than being created by the fuzzers themselves, seed corpora are often prepared from existing test inputs or may be hand-crafted to provide interesting coverage. They are often checked into source alongside [fuzz targets](#fuzz-target).
+
+### References
+
+- https://github.com/google/centipede#terminology
+- https://github.com/google/fuzzing/blob/master/docs/glossary.md
+- https://google.github.io/clusterfuzz/reference/glossary/
+- https://google.github.io/oss-fuzz/reference/glossary/
+- https://github.com/ligurio/trash-software-bugs
+- https://csrc.nist.gov/glossary
+- https://xlinux.nist.gov/dads/
+- https://github.com/jagracey/Awesome-Unicode/blob/master/GLOSSARY.md#r
+- ISTQB Glossary https://glossary.istqb.org/en/search/
+- https://en.wikipedia.org/wiki/Buffer_overflow
+- https://en.wikipedia.org/wiki/Segmentation_fault
+- https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
\ No newline at end of file
