| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
There's no reason to do first one and then another.
|
| |
|
|
|
| |
Specify a track name for each fuzzing campaign.
It will help distinguish them once there are multiple ones.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Adjut the workflow template and the API to run multiple fuzzing
campaigns as a part of single patch series processing.
|
| |
|
|
|
|
|
|
| |
First build and boot test the base kernel, then proceed to the patched
kernel.
It prevents us from reporting build/boot errors not introduced by the
patch.
|
| |
|
|
|
|
|
|
| |
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 used to only upload them on triage failure, but let's improve the
inspectability even for successfully finished triage jobs.
Slightly refactor the controller API around the triage result
submission.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Enable egress traffic for all nodes.
Configure ingress traffic on the per-need basis.
|
| |
|
|
|
| |
Poll the status more often.
Configure auto-deletion of pods and workflows.
|
| |
|
|
| |
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/*.
|
