| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
When configuring focus areas before directed fuzzing, construct regular
expressions that match the exact function names. Otherwise, we end up
adding more functions than intended.
|
| |
|
|
| |
Return not just the modified files, but also their blob hashes.
|
| |
|
|
| |
Any is the preferred over interface{} now in Go.
|
| |
|
|
|
|
|
| |
There are still situations where we don't properly terminate fuzzing on
context cancelation.
Add more logging to debug it.
|
| |
|
|
|
| |
We don't need it to hold it for the call to the externally supplied
callback.
|
| |
|
|
|
| |
Instead of just checking whether the bug was observed on the base crash,
accept a regexp of accepted bug titles as well.
|
| | |
|
| |
|
|
|
|
|
| |
When we run a reproducer on a base kernel and it crashes, we must record
the crash title observed on the base kernel.
Rename the field to reduce the chance of confusion in the future.
|
| |
|
|
|
|
| |
Report base kernel crashes observed during fuzzing.
Consult the common API for each patched kernel crash to see if it was
already observed on the base kernel.
|
| |
|
|
|
| |
1. func Run optionally accepts the opts.
2. Some refactoring, more comments.
|
| |
|
|
| |
The VM pool expects us to listen on the boot error channel.
|
| |
|
|
|
| |
It's been checking the inverse of what was needed.
Rename the helper function to reduce confusion in the future.
|
| |
|
|
|
|
| |
Instead of calling grep (the implementations of which may differ in
different environments), traverse the directory and grep files with a
special pkg/osutil helper functionality.
|
| |
|
|
|
|
|
| |
The rules were too generic - there are plenty of functions that have
"stall" as substring, yet they do not relate to rcu stall bugs.
Improve the rules list and add a unit test.
|
| |
|
|
|
|
|
|
| |
After ensuring that a bug only affects the patched kernel, do one more
round of reproduction and (if successful) re-report the result.
This will ensure that, provided enough time, diff fuzzing results will
also have minimalistic C reproducers.
|
| |
|
|
|
| |
The previous message was misleading - executor's coverage filter can
well be 0, it's the number of PCs per focus area that's of interest.
|
| |
|
|
| |
Right at the Loop() start, these are not filled out yet.
|
| |
|
|
|
|
|
|
|
| |
Hash the code section of the individual symbols from vmlinux.o and use
it to determine the functions that changed their bodies between the base
and the patched build.
If the number of affected symbols is reasonable (<5%), fuzz it with the
highest priority.
|
| |
|
|
| |
These are already symbolized in pkg/repro.
|
| |
|
|
|
| |
If we matched 0 PCs for the areas of focused fuzzing, don't abort the
process after 30 minutes.
|
| |
|
|
|
| |
Use the context provided via errgroup.Group so that a single error can
successfully shut down the whole diff fuzzing process.
|
| |
|
|
|
| |
Don't waste time doing focused fuzzing if no modified code has
been reached in 30 minutes after corpus triage.
|
| |
|
|
|
|
| |
In syz-manager, we symbolize reports right before saving them. Follow a
similar approach for diff fuzzing as well and symbolize only the reports
which were confirmed to only affect the patched kernel.
|
| |
|
|
|
|
| |
During diff fuzzing, ignore too unreliable reproducers completely.
For moderately reliable ones, do a larger number of runs.
|
| |
|
|
| |
It allows to use context as a single termination signal source.
|
| |
|
|
|
|
|
|
|
| |
When running the reproducer from the patched kernel on the base kernel,
stay on the safe side when encountering errors and context
cancellations.
Always demand 3 successful executions before declaring a bug
patched-only.
|
| |
|
|
|
|
|
| |
Writes to channels are dangerous in the presence of context cancellation
- no one may be listening on the receiving side.
Wrap the writes in a select that also awaits ctx.Done().
|
| |
|
|
|
|
|
| |
It's still unclear what exactly is causing the fuzzer to not halt at
context cancellation.
Log the termination of the internal syz-diff loops.
|
| |
|
|
|
|
|
|
|
|
| |
Make the pool.Run() function take a context.Context to be able to abort
the callback passed to it or abort its scheduling if it's not yet
running.
Otherwise, if the callback is not yet started and the pool's Loop is
aborted, we risk waiting for pool.Run() forever. It prevents the normal
shutdown of repro.Run() and, consequently, the DiffFuzzer functionality.
|
| |
|
|
|
|
| |
Make the fuzzing step of syz-cluster create the manager.DiffStore object
explicitly and dump its state to the logs after finishing the fuzzing
session.
|
| |
|
|
|
| |
If the context is cancelled, we need to make sure that the reproduction
process is aborted as well.
|
| |
|
|
|
|
|
| |
It may be introducing false positives into the process of determining
whether the bug affects the base kernel.
Let's stay on the safe side and not do it for now.
|
| |
|
|
|
| |
While doing a blocking write to the channel, take the possibility of the
context closure into account.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It might be possible that:
1) The reproducer did not crash the base kernel.
2) Yet the base kernel has crashed with the same title independently
since the moment we have started to find the reproducer etc.
It should not be normally happening (it means that the current mechanism
of checking whether the bug affects the base kernel is flawed), but it
still happens.
Add an extra check to avoid reporting such false positives and call
log.Errorf() to ensure that the situation will be recorded in the logs.
|
| |
|
|
|
|
| |
Add some comments.
Demand that the channel for patched-only bugs is always present -
otherwise what's the purpose of doing it.
|
| |
|
|
|
|
|
|
|
|
|
| |
Track the right moment to start bug reproductions more exactly:
1) Either once 90% of the corpus is triaged (*).
2) Or once we are past 50% of the time dedicated for fuzzing.
Whatever happens earlier.
(*) The last percents are usually quite slow and they bring much less
covered PCs that all the previous ones.
|
| | |
|
| |
|
|
| |
There were a few spots where they were not considered.
|
| |
|
|
| |
Run differential fuzzing as a workflow step.
|
| |
|
|
| |
We must not only call Listen(), but also Serve().
|
| |
|
|
|
| |
Make the method more flexible.
Rename the variables to better reflect what is being done.
|
| |
|
|
|
| |
There's a 15 minutes timer in the diff fuzzer that needs to be
conditional on the context object.
|
| |
|
|
| |
Apply necessary changes to pkg/flatrpc and pkg/manager as well.
|
| |
|
|
| |
This enables graceful error handling in the caller code.
|
| | |
|
|
|
This is the prototype version of the patch series fuzzing functionality
based on the syzkaller fuzzing engine.
The tool takes two syzkaller configs -- one for the base kernel, one for
the patched kernel. Optionally the patch itself can be also provided.
syz-diff will consider a bug patched-only if:
1) It happened while fuzzing the patched kernel.
2) It was never observed on the base kernel.
3) The tool found a repro on the patched kernel.
4) The repro did not crash the base kernel.
|