more FAQ

1 files changed, 65 insertions, 13 deletions

diff --git a/docs/FAQ.md b/docs/FAQ.md
index 997f4c40..93a87a72 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -2,16 +2,39 @@
 
 ## Contents
 
-  1. [How to improve the fuzzing speed?](#how-to-improve-the-fuzzing-speed)
-  2. [How do I fuzz a network service?](#how-to-fuzz-a-network-service)
-  3. [How do I fuzz a GUI program?](#how-to-fuzz-a-gui-program)
-  4. [What is an edge?](#what-is-an-edge)
-  5. [Why is my stability below 100%?](#why-is-my-stability-below-100)
-  6. [How can I improve the stability value](#how-can-i-improve-the-stability-value)
+  * [What is the difference between afl and afl++?](#what-is-the-difference-between-afl-and-afl)
+  * [How to improve the fuzzing speed?](#how-to-improve-the-fuzzing-speed)
+  * [How do I fuzz a network service?](#how-to-fuzz-a-network-service)
+  * [How do I fuzz a GUI program?](#how-to-fuzz-a-gui-program)
+  * [What is an edge?](#what-is-an-edge)
+  * [Why is my stability below 100%?](#why-is-my-stability-below-100)
+  * [How can I improve the stability value](#how-can-i-improve-the-stability-value)
 
 If you find an interesting or important question missing, submit it via
 [https://github.com/AFLplusplus/AFLplusplus/issues](https://github.com/AFLplusplus/AFLplusplus/issues)
 
+## What is the difference between afl and afl++?
+
+American Fuzzy Lop (AFL) was developed by Michał "lcamtuf" Zalewski starting in
+2013/2014, and when he left Google end of 2017 he stopped developing it.
+
+At the end of 2019 the Google fuzzing team took over maintance of AFL, however
+it is only accepting PR from the community and is not developing enhancements
+anymore.
+
+In the second quarter of 2019, 1 1/2 years after no further development of
+AFL had happened and it became clear there would be none coming, afl++
+was born, where initially first community patches were collected and applied
+for bugs and enhancements. Then from various AFL spin-offs - mostly academic
+research - features were integrated. This already resulted in a much advanced
+AFL.
+
+Until the end of 2019 the afl++ team had grown to four active developers which
+then implemented their own research and feature, making it now by far the most
+flexible and feature rich guided fuzzer available as open source.
+And in independent fuzzing benchmarks it is one of the best fuzzers available,
+e.g. [Fuzzbench Report](https://www.fuzzbench.com/reports/2020-08-03/index.html)
+
 ## How to improve the fuzzing speed
 
   1. use [llvm_mode](docs/llvm_mode/README.md): afl-clang-lto (llvm >= 11) or afl-clang-fast (llvm >= 9 recommended)
@@ -101,15 +124,15 @@ code example above):
 ```
 Every line between two blocks is an `edge`.
 
-## Why is my stability below 100
+## Why is my stability below 100%
 
 Stability is measured by how many percent of the edges in the target are
 "stable". Sending the same input again and again should take the exact same
 path through the target every time. If that is the case, the stability is 100%.
 
-If however randomness happens, e.g. a thread reading from shared memory,
+If however randomness happens, e.g. a thread reading other external data,
 reaction to timing, etc. then in some of the re-executions with the same data
-will result in the edge information being different accross runs.
+the result in the edge information will be different accross runs.
 Those edges that change are then flagged "unstable".
 
 The more "unstable" edges, the more difficult for afl++ to identify valid new
@@ -122,9 +145,25 @@ improve the stability.
 
 ## How can I improve the stability value
 
+For fuzzing a 100% stable target that covers all edges is the best.
+A 90% stable target that covers all edges is however better than a 100% stable
+target that ignores 10% of the edges.
+
+With instability you basically have a partial coverage loss on an edge, with
+ignore you have a full loss on that edge.
+
+There are functions that are unstable, but also provide value to coverage, eg
+init functions that use fuzz data as input for example.
+If however it is a function that has nothing to do with the input data is the
+source, e.g. checking jitter, or is a hash map function etc. then it should
+not be instrumented.
+
+To be able to make this decision the following process will allow you to
+identify the functions with variable edges so you can make this decision.
+
 Four steps are required to do this and requires quite some knowledge of
 coding and/or disassembly and it is only effectively possible with
-afl-clang-fast PCGUARD and afl-clang-lto LTO instrumentation!
+afl-clang-fast PCGUARD and afl-clang-lto LTO instrumentation.
 
   1. First step: Identify which edge ID numbers are unstable
 
@@ -135,9 +174,9 @@ afl-clang-fast PCGUARD and afl-clang-lto LTO instrumentation!
   2. Second step: Find the responsible function.
 
      a) For LTO instrumented binaries this can be documented during compile
-        time, just set `export AFL_LLVM_DOCUMENT_IDS=/path/to/afile`.
-        This file will have one assigned edge ID and the corresponding function
-        per line.
+        time, just set `export AFL_LLVM_DOCUMENT_IDS=/path/to/a/file`.
+        This file will have one assigned edge ID and the corresponding
+        function per line.
 
      b) For PCGUARD instrumented binaries it is much more difficult. Here you
         can either modify the __sanitizer_cov_trace_pc_guard function in
@@ -151,6 +190,10 @@ afl-clang-fast PCGUARD and afl-clang-lto LTO instrumentation!
         on start, check to which memory address the edge ID value is written
         and set a write breakpoint to that address (`watch 0x.....`).
 
+     c) in all other instrumentation types this is not possible. So just
+        recompile with the the two mentioned above. This is just for
+        identifying the functions that have unstable edges.
+
   3. Third step: create a text file with the filenames/functions
 
      Identify which source code files contain the functions that you need to
@@ -161,6 +204,15 @@ afl-clang-fast PCGUARD and afl-clang-lto LTO instrumentation!
      If PCGUARD is used, then you need to follow this guide (needs llvm 12+!):
      [http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation)
 
+     Only deny those functions from instrumentation that provide no value
+     for coverage - that is if it does not process any fuzz data directly
+     or indirectly (e.g. hash maps, thread management etc.).
+     If however a function directly or indirectly handles fuzz data then you
+     should not put the function in a deny instrumentation list and rather
+     live with the instability it comes with.
+
   4. Fourth step: recompile the target
 
      Recompile, fuzz it, be happy :)
+
+     This link explains this process for [Fuzzbench](https://github.com/google/fuzzbench/issues/677)