| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
These will allow pkg/cover work as intended.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Share not just the tree name (mainline, net, etc), but also the full URL
to check out the repository.
For that, add one more field to the Build entity and adjust email
reporting templates.
|
| |
|
|
|
| |
For some reason, it does not download the newer toolchain versions
automatically.
|
| | |
|
| |
|
|
| |
This prevents bind() and connect() from being disabled. See #6171.
|
| |
|
|
| |
Extract Report/Log from the errors returned by build.Image().
|
| |
|
|
|
|
| |
Retry the boot test up to 3 times before letting it fail and reporting
the failure as a finding. That should make sure there are fewer false
positives amoung the "boot error" and "test error" bugs.
|
| |
|
|
|
| |
Move C repro generation from syz-manager to pkg/repro to avoid code
duplication.
|
| |
|
|
|
| |
Before incorporating it into the process, let's see how reliable this
value is at the moment.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
These cause too many irrelevant crashes and distract the diff fuzzer.
Disable the related syscalls until we're able to adjust them
automatically.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
For now, only share it for the skipped series.
|
| |
|
|
|
|
|
|
| |
The existing "no suitable commits found" reason is way too ambiguous.
Make CommitSelector return the exact reason why it decides not to
proceed with the particular patch series and display the reason on the
web dashboard.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
Refactor Tree structure to host both the kernel config and the fuzzer
config.
Add some basic net fuzzing configs.
|
| |
|
|
|
| |
Use the simplest possible configurations for now.
For some reason, this folder was forgotten in the previous PRs.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Once a new kernel revision becomes available, build it to figure out
whether it's buildable. This information will be used in the triage step
to figure out the right base kernel revision.
|
| |
|
|
| |
This removes one of the required manual steps.
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of giving several base commits to try, make the more concrete
decision at the triage step and return only one option.
This relies on the triager always having the information about the
current state of the each tree, which will be added in the following
commit.
As the result, the workflow script becomes much simpler.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Use the syzbot container as the base.
Use ADD instead of wget.
|
| |
|
|
| |
Record the logs from the build and fuzzing steps.
|
| |
|
|
| |
Run differential fuzzing as a workflow step.
|
| | |
|
| |
|
|
|
|
|
|
| |
It lets immediately distinguish the series that were actually processed
from the series that were skipped early on.
By storing a string, we also make it apparent why exactly the series was
skipped.
|
| |
|
|
| |
Report the findings only for the boot test of the patched kernel.
|
| |
|
|
| |
Run a smoke test on the base kernel build and report back the results.
|
| |
|
|
|
|
|
| |
It's not necessary - submit the results from the individual steps
instead.
Report patched kernel build failures as findings.
|
|
|
The basic code of a K8S-based cluster that:
* Aggregates new LKML patch series.
* Determines the kernel trees to apply them to.
* Builds the basic and the patched kernel.
* Displays the results on a web dashboard.
This is a very rudimentary version with a lot of TODOs that
provides a skeleton for further work.
The project makes use of Argo workflows and Spanner DB.
Bootstrap is used for the web interface.
Overall structure:
* syz-cluster/dashboard: a web dashboard listing patch series
and their test results.
* syz-cluster/series-tracker: polls Lore archives and submits
the new patch series to the DB.
* syz-cluster/controller: schedules workflows and provides API for them.
* syz-cluster/kernel-disk: a cron job that keeps a kernel checkout up to date.
* syz-cluster/workflow/*: workflow steps.
For the DB structure see syz-cluster/pkg/db/migrations/*.
|
