doc: Listing mutators in the module documentation (#2369)

* doc(libafl_nyx): More detailed README

* doc(libafl): Documentation about mutators

* doc(libafl): fix Reference to MOpt

* doc(libafl): Improved note about Mopt

* doc: More documentation for different mutators

docs/src/core_concepts/mutator.md

@@ -6,4 +6,6 @@ Mutators can be composed, and they are generally linked to a specific Input type
 
 There can be, for instance, a Mutator that applies more than a single type of mutation to the input. Consider a generic Mutator for a byte stream, bit flip is just one of the possible mutations but not the only one, there is also, for instance, the random replacement of a byte of the copy of a chunk.
 
+There are also mutators that always produce valid inputs, say a mutator that generates valid JSON or code, but these grammar based mutators need a grammar to work.
+
 In LibAFL, [`Mutator`](https://docs.rs/libafl/latest/libafl/mutators/trait.Mutator.html) is a trait.

libafl/src/mutators/gramatron.rs

@@ -1,4 +1,4 @@
-//! Gramatron is the rewritten gramatron fuzzer in rust.
+//! [`GramatronRandomMutator`] ist a random mutator using grammar automatons to perform grammar-aware fuzzing.
 //! See the original gramatron repo [`Gramatron`](https://github.com/HexHive/Gramatron) for more details.
 use alloc::{borrow::Cow, vec::Vec};
 use core::cmp::max;

libafl/src/mutators/mod.rs

@@ -1,5 +1,5 @@
-//! [`Mutator`]`s` mutate input during fuzzing.
-
+//! [`Mutator`]`s` mutate input during fuzzing. These can be used standalone or in combination with other mutators to explore the input space more effectively.
+//! You can read more about mutators in the [libAFL book](https://aflplus.plus/libafl-book/core_concepts/mutator.html)
 pub mod scheduled;
 use core::fmt;
 

libafl/src/mutators/mopt_mutator.rs

@@ -1,4 +1,5 @@
-//! The `MOpt` mutator scheduler, see <https://github.com/puppet-meteor/MOpt-AFL> and <https://www.usenix.org/conference/usenixsecurity19/presentation/lyu>
+//! The `MOpt` mutation scheduler used in AFL++. It uses a modified Particle Swarm Optimization algorithm to determine an optimal distribution of mutators.
+//! See <https://github.com/puppet-meteor/MOpt-AFL> and <https://www.usenix.org/conference/usenixsecurity19/presentation/lyu>
 use alloc::{borrow::Cow, string::ToString, vec::Vec};
 use core::{
     fmt::{self, Debug},
@@ -22,7 +23,7 @@ use crate::{
 /// A Struct for managing MOpt-mutator parameters.
 /// There are 2 modes for `MOpt` scheduler, the core fuzzing mode and the pilot fuzzing mode.
 /// In short, in the pilot fuzzing mode, the fuzzer employs several `swarms` to compute the probability to choose the mutation operator.
-/// On the other hand, in the core fuzzing mode, the fuzzer chooses the best `swarms`, which was determined during the pilot fuzzing mode, to compute the probability to choose the operation operator.
+/// On the other hand, in the core fuzzing mode, the fuzzer chooses the best `swarms`, which was determined during the pilot fuzzing mode, to compute the probability to choose the mutation operator.
 /// With the current implementation we are always in the pacemaker fuzzing mode.
 #[derive(Serialize, Deserialize, Clone)]
 #[cfg_attr(

libafl/src/mutators/nautilus.rs

@@ -1,5 +1,5 @@
 //! Mutators for the `Nautilus` grammmar fuzzer
-
+//! See <https://www.ndss-symposium.org/ndss-paper/nautilus-fishing-for-deep-bugs-with-grammars/>
 use alloc::borrow::Cow;
 use core::fmt::Debug;
 

libafl_bolts/src/cpu.rs

@@ -1,4 +1,4 @@
-//! Architecture agnostic processor features
+//! Fast implementations for specific CPU architectures.
 
 #[cfg(any(target_arch = "aarch64", target_arch = "arm"))]
 use core::arch::asm;

libafl_nyx/README.md

@@ -1,4 +1,5 @@
-`libafl_nyx` is the `libafl`'s front-end for nyx fuzzer. This crate provides both the standalone mode and parallel mode:
+`libafl_nyx` is the `libafl`'s front-end for the [nyx fuzzing framework](https://github.com/nyx-fuzz), which facilitates fuzzing in virtual machines such as qemu. This crate provides both the standalone mode and parallel mode:
+
 - In standalone mode, no VM snapshot is serialized and stored in the working directory. That might be useful if you really want to run the fuzzer with only one process (meaning one VM).
 - In parallel mode, the first fuzzer process (parent) has to create the VM snapshot while all other child processes will wait for the snapshot files to appear in the working directory.