| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Copy everything into the build context.
Add a .dockerignore file to avoid copying the definitely unnecessary
files and folders.
Check copyrights presence in Dockerfiles.
|
| |
|
|
|
|
|
|
| |
Instead of a predefined set of manually written syz-manager configs,
construct it dynamically from different bits.
During triage, select not just one, but all matching fuzzer
configurations and then merge them together.
|
| |
|
|
|
|
| |
3G is not enough for kernels with KMSAN.
Slightly decrease the number of used VMs to fit into the available
CPUs/RAM.
|
| |
|
|
|
| |
Specify a track name for each fuzzing campaign.
It will help distinguish them once there are multiple ones.
|
| |
|
|
|
| |
Instead of just checking whether the bug was observed on the base crash,
accept a regexp of accepted bug titles as well.
|
| |
|
|
|
|
| |
Instead of passing the values individually, save the FuzzConfig object
as JSON and pass it as an artifact. This will simplify adding more new
fields.
|
| |
|
|
|
| |
If the archive turned out to be too large, just print an error message
and don't return an error from the status update function.
|
| |
|
|
|
|
|
|
|
|
| |
It does happen that we detect a bug that was introduced in the patch
series, but we don't report it becase no reliable reproducer was found.
Let's at least log such cases to better understand the scale of the
problem.
10 is an arbitrary cut-off value.
|
| |
|
|
|
|
|
|
|
| |
When determining whether a patch series is worth fuzzing, consider not
only the hashes of .text symbols, but also the hashes of the global
(static and non-static) variables.
As before, calculate the hashes during build and process them at the
beginning of the fuzz step.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
And improve the tests for the method.
|
| |
|
|
|
|
|
|
| |
If all symbol hashes between the base and the pathed kernel match,
there's no reason to spend time fuzzing the series.
Add a 'skipped' status to the enum of possible session test results and
set it from the fuzz-step.
|
| |
|
|
|
| |
Use a smaller upper limit on CPUs since we're now using 32 Core nodes.
Request at least 3GB/VM of RAM.
|
| |
|
|
|
|
|
|
| |
There are cases when we do not need the "if the patched code is not
reached within 30 minutes, abort fuzzing" check.
This is e.g. the case of mm/ code that is not fully instrumented by
KCOV.
|
| |
|
|
| |
We use it for C repros by default.
|
| |
|
|
| |
It's required by pkg/csource to generate C reproducers.
|
| |
|
|
|
|
|
| |
The fuzzing step only takes inputs and communicates via API.
This will reduce the number of
Error: open /mainctrfs/output/result.json: no such file or director
errors in our logs.
|
| |
|
|
| |
It's required for report symbolization and C repro generation.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Don't waste time doing focused fuzzing if no modified code has
been reached in 30 minutes after corpus triage.
|
| |
|
|
|
| |
Move C repro generation from syz-manager to pkg/repro to avoid code
duplication.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Some of the fuzz jobs seem to be unable to finish in time.
Add some logging to better understand what part if preventing
the termination.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Compress and upload the artifacts folder every 30 minutes of fuzzing and
once after the fuzzing is completed.
|
| |
|
|
|
| |
If we build the executor from an incomplete workdir, executor and the
host process end up having different git revisions.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Accept IMAGE_PREFIX and IMAGE_TAG parameters that allow to reuse the
Makefile and a lot of k8s configurations both for local and prod
environments.
Refactor Makefile: define build-* and push-* rules, use templates to
avoid repetition.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Provide an API to set up the reporting of finished sessions for which
syz-cluster collected reportable findings.
The actual sending of the results is to be done in a separate component
that would:
1) Call Next() to get the next report to send.
2) Call Confirm() to confirm that the report has been sent.
3) Call Upstream() if the report has been moderated and needs to be sent
to e.g. public mailing lists.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the previous version of the code, series-tracker was directly pushing
patch series into the DB and the controller auto-created fuzzing
sessions.
Mediate these via the controller API instead.
Instead of creating Session objects on the fly, pre-create them and
let processor take them one by one.
The approach has multiple
benefits:
1) The same API might be used for the patch series sources other than
LKML.
2) If the existence of Session objects is not a sign that we have
started working on it, it allows for a more precise status display
(not created/waiting/running/finished).
3) We could manually push older patch series and manually trigger
fuzzing sessions to experimentally measure the bug detection rates.
4) The controller tests could be organized only by relying on the API
offered by the component.
|
| |
|
|
| |
2h session is too short (at least for now).
|
| |
|
|
|
| |
It will be important once we deploy to GKE.
For now, let's set just some limits, we'll adjust them over time.
|
| |
|
|
|
|
| |
We cannot use the single context with a deadline for all processing
because it does not let us report the final status after finishing
fuzzing.
|
|
|
Run differential fuzzing as a workflow step.
|
