Merge "common_sense_risks.md" into "fuzzing_in_depth.md"

3 files changed, 39 insertions, 38 deletions

diff --git a/README.md b/README.md
index e0cb4558..989e8fdb 100644
--- a/README.md
+++ b/README.md
@@ -60,8 +60,8 @@ To build AFL++ yourself, continue at [docs/INSTALL.md](docs/INSTALL.md).
 
 ## Quick start: Fuzzing with AFL++
 
-*NOTE: Before you start, please read about the [common sense risks of
-fuzzing](docs/common_sense_risks.md).*
+*NOTE: Before you start, please read about the
+[common sense risks of fuzzing](docs/fuzzing_in_depth.md#0-common-sense-risks).*
 
 This is a quick start for fuzzing targets with the source code available. To
 read about the process in detail, see
diff --git a/docs/common_sense_risks.md b/docs/common_sense_risks.md
deleted file mode 100644
index a8d68d7a..00000000
--- a/docs/common_sense_risks.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Common sense risks
-
-Please keep in mind that, similarly to many other computationally-intensive
-tasks, fuzzing may put a strain on your hardware and on the OS. In particular:
-
-  - Your CPU will run hot and will need adequate cooling. In most cases, if
-    cooling is insufficient or stops working properly, CPU speeds will be
-    automatically throttled. That said, especially when fuzzing on less
-    suitable hardware (laptops, smartphones, etc), it's not entirely impossible
-    for something to blow up.
-
-  - Targeted programs may end up erratically grabbing gigabytes of memory or
-    filling up disk space with junk files. AFL++ tries to enforce basic memory
-    limits, but can't prevent each and every possible mishap. The bottom line
-    is that you shouldn't be fuzzing on systems where the prospect of data loss
-    is not an acceptable risk.
-
-  - Fuzzing involves billions of reads and writes to the filesystem. On modern
-    systems, this will be usually heavily cached, resulting in fairly modest
-    "physical" I/O - but there are many factors that may alter this equation.
-    It is your responsibility to monitor for potential trouble; with very heavy
-    I/O, the lifespan of many HDDs and SSDs may be reduced.
-
-    A good way to monitor disk I/O on Linux is the 'iostat' command:
-
-```shell
-    $ iostat -d 3 -x -k [...optional disk ID...]
-```
-
-    Using the `AFL_TMPDIR` environment variable and a RAM-disk you can have the
-    heavy writing done in RAM to prevent the aforementioned wear and tear. For
-    example the following line will run a Docker container with all this preset:
-    
-    ```shell
-    # docker run -ti --mount type=tmpfs,destination=/ramdisk -e AFL_TMPDIR=/ramdisk aflplusplus/aflplusplus
-    ```
\ No newline at end of file
diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 4481bce6..19d8e783 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -13,6 +13,43 @@ Fuzzing source code is a three-step process:
 3. Perform the fuzzing of the target by randomly mutating input and assessing if
    a generated input was processed in a new path in the target binary.
 
+### 0. Common sense risks
+
+Please keep in mind that, similarly to many other computationally-intensive
+tasks, fuzzing may put a strain on your hardware and on the OS. In particular:
+
+- Your CPU will run hot and will need adequate cooling. In most cases, if
+  cooling is insufficient or stops working properly, CPU speeds will be
+  automatically throttled. That said, especially when fuzzing on less suitable
+  hardware (laptops, smartphones, etc.), it's not entirely impossible for
+  something to blow up.
+
+- Targeted programs may end up erratically grabbing gigabytes of memory or
+  filling up disk space with junk files. AFL++ tries to enforce basic memory
+  limits, but can't prevent each and every possible mishap. The bottom line is
+  that you shouldn't be fuzzing on systems where the prospect of data loss is
+  not an acceptable risk.
+
+- Fuzzing involves billions of reads and writes to the filesystem. On modern
+  systems, this will be usually heavily cached, resulting in fairly modest
+  "physical" I/O - but there are many factors that may alter this equation. It
+  is your responsibility to monitor for potential trouble; with very heavy I/O,
+  the lifespan of many HDDs and SSDs may be reduced.
+
+  A good way to monitor disk I/O on Linux is the `iostat` command:
+
+  ```shell
+  $ iostat -d 3 -x -k [...optional disk ID...]
+  ```
+
+  Using the `AFL_TMPDIR` environment variable and a RAM-disk, you can have the
+  heavy writing done in RAM to prevent the aforementioned wear and tear. For
+  example, the following line will run a Docker container with all this preset:
+
+  ```shell
+  # docker run -ti --mount type=tmpfs,destination=/ramdisk -e AFL_TMPDIR=/ramdisk aflplusplus/aflplusplus
+  ```
+
 ### 1. Instrumenting the target
 
 #### a) Selecting the best AFL++ compiler for instrumenting the target