regex is a large crate, and is only used in a few specific spots. Users should
have the ability to avoid this transitive dependency if not using the features
in question.
* Don't use magic string but string constant
* Don't allow to specify multiple input files with different names
* Ensure that the file name for the current test case is unique for every fuzzer currently running
* Add note advising users to choose distinct names for the input file
* Move builder functions to more generic implementation to allow parse_afl_cmdline rewrite
* Rewrite parse_afl_cmdline to reduce code duplication
* Add remark to documentation regarding the program path
* Change behavior to allow the usage of actual AFL command lines, hopefully without breaking existing code
* Rustfmt
* Move generation of unique filename to fs
* Ensure default input filename for command executor is unique per fuzzing process
* Pass the input to the target via stdin, when no input file is specified
Previous solution of passing it via a standard file is useless, as the target does not know to read said file
* Rustfmt
---------
Co-authored-by: Dominik Maier <domenukk@gmail.com>
Co-authored-by: Dongjia "toka" Zhang <tokazerkje@outlook.com>
* scheduler replace fixes
* oops, no-std
* add
* changes on the fuzzers
* move map feedback history updates to append_metadata
* fixes for python bindings
* learn to clippy
* fix for fuzzer add_input
* clippy fixes for frida
* additional powersched differences
* corrections for bitmap_size
* off-by-one
* I live in a prison of my own creation and clippy is the warden
* clear the novelties map for the situation where is_interesting is invoked, but not append_metadata
---------
Co-authored-by: tokatoka <tokazerkje@outlook.com>
* Use Instant::now instead of duration
* Use Some
* add custom serde for Instant
* fix linter
* only enable TimeFeedback when std flag is enabled
* fix typo
* fix linter std
* cargo fmt
* allow clippy::trivially_copy_pass_by_ref on custom serde serialize function
* allow TimeObserver and Timefeedback for no_std
* cargo fmt
---------
Co-authored-by: Andrea Fioraldi <andreafioraldi@gmail.com>
Reduces total number of packages from 577 to 571 on building with:
`cargo +nightly build --workspace --all-features`
* ahash 0.7 -> 0.8
* Move `AHasher::new_with_keys` to `RandomState::with_seeds` given the
recommendation from: aHash maintainer:
https://github.com/tkaitchuck/aHash/issues/132#issuecomment-1288207069
* bindgen: 0.61 -> 0.63
* c2rust-bitfields: 0.3 -> 0.17
* criterion: 0.3 -> 0.4
* crossterm: 0.25 -> 0.26
* dynasmrt: 1.2 -> 2
* goblin: 0.5.3 -> 0.6
* hashbrown: 0.12 -> 0.13
* nix: 0.25 -> 0.26
* The `addr` arg of `mmap` is now of type `Option<NonZeroUsize>`
* The `length` arg of `mmap` is now of type `NonZeroUsize`
* Requires updating implementers to update `nix` as well
* prometheus-client: 0.18.0 -> 0.19
* Do not box metrics
* Gauges (a majority of the LibAFL metrics) are now i64 types so there
is a small chance of overflow, with the u64 values that LibAFL
tracks, but unlikely to be problematic.
* Keep `exec_rate` as a floating point value
* serial_test: 0.8 -> 1
* typed-builder: 0.10.0 -> 0.12
* windows: 0.42.0 -> 0.44
Co-authored-by: Dominik Maier <domenukk@gmail.com>
Most of the time, fuzzing campaigns are reasonably long. Accordingly, when
using `NewHashFeedback`, you might have good reason to believe that you'll
find thousands (or more) different observations with different hashes. When
the `HashSet` outgrows its capacity, it can cause reallocation, which is slow.
See the following link for more details:
https://doc.rust-lang.org/std/vec/struct.Vec.html#capacity-and-reallocation
* libafl: Remove `{update,clear}_hash` from `ObserverWithHashField`
These methods aren't used by `NewHashFeedback`, so there's no compelling reason
to keep them in the interface. They preclude implementations of
`ObserverWithHashField` that calculcate a hash on-the-fly from a value. For
example, my use-case is to store the stdout of a process, and use
`NewHashFeedback` to only collect inputs that result in new messages on stdout.
Both of these methods are pretty suspicious to begin with - why should other
code be able to update the internal state of the observer? What are the
semantics of `update_hash`? If there are compelling reasons to keep these
methods, let's clarify their intent in the documentation.
* libafl: Return hash by value from `ObserverWithHashField`
This allows implementors of this trait to not store the hash, but rather to
compute it on-the-fly. Since `Option<u64>` is `Copy` (and quite small), and
this method is called once per execution of the target program, this is likely
to have negligible performance impact.
* libafl: Implement `ObserverWithHashField` for `ValueObserver`
This demonstrates the utility of the previous two commits. Now, `ValueObserver`
can be used with `NewHashFeedback`.
* Clippy, move to ahasher
* Oops :)
---------
Co-authored-by: Langston Barrett <langston.barrett@gmail.com>
