| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step for #1541.
Move the fuzzing engine that used to be interleaved with other syz-fuzzer
code into a separate package.
For now, the algorithm is more or less the same as it was, the only
difference is that a pkg/fuzzer instance scales to the available
computing power.
Add an executor-based test that performs real fuzzing.
|
| |
|
|
|
| |
If the original call was successful, keep it successful during minimization.
Successful calls are much more valuable.
|
| |
|
|
|
|
|
| |
5 bool's in a row is too much.
2 are unnecessary because they control execOpts,
and we already pass execOpts in.
Combine the remaining 3 into ProgFlags field.
|
| |
|
|
|
|
|
|
|
|
| |
By default we don't re-minimize/re-smash programs from corpus,
it takes lots of time on start and is unnecessary.
However, when we improve/fix minimization/smashing,
we may want to.
Introduce corpus database versions and allow to re-minimize/re-smash
on version bumps.
|
|
|
syz-fuzzer organically grew from a small nice main function
into a huge single-file monster with tons of global state.
Start refactoring it into something more managable.
This change separates 2 things:
1. Proc: a single fuzzing process (ipc.Env wrapper).
2. WorkQueue: holds global non-fuzzing work items.
More work needed, but this is good first step.
|