Skip to content

Conversation

a-nogikh
Copy link
Collaborator

@a-nogikh a-nogikh commented Sep 4, 2025

A set of refactorings and enhancements for syz-cluster to support running multiple fuzzing campaigns per each patch series.

For networking series, build and fuzz a CONFIG_KMSAN=y kernel in addition to fuzzing the KASAN kernel.

Instead of picking one of the predefined fuzzer configuration, construct the resulting config from all the matching configuration bits.

@a-nogikh a-nogikh marked this pull request as ready for review September 4, 2025 20:13
@a-nogikh a-nogikh requested a review from tarasmadan September 4, 2025 20:13
@a-nogikh a-nogikh force-pushed the features/syz-cluster-kmsan branch 3 times, most recently from 80c0327 to 5359099 Compare September 15, 2025 09:12
@a-nogikh a-nogikh changed the title syz-cluster: fuzz with KMSAN syz-cluster: assorted updates Sep 18, 2025
@a-nogikh a-nogikh force-pushed the features/syz-cluster-kmsan branch 3 times, most recently from cd28977 to 28c6fa9 Compare September 19, 2025 18:33
@a-nogikh a-nogikh force-pushed the features/syz-cluster-kmsan branch 3 times, most recently from 1b93a29 to 364d86b Compare September 23, 2025 17:12
parameters:
- name: test-name
value: "Build Base"
value: "Build Base{{=jsonpath(inputs.parameters.element, '$.suffix')}}"
Copy link
Collaborator

@tarasmadan tarasmadan Sep 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will we have " " after "Base" word?

fsCorpusURL = `https://storage.googleapis.com/syzkaller/corpus/ci2-upstream-fs-corpus.db`
)

const kasanSuffix = " [KASAN]"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

" [...]" part here is a formatting detail.
I think testName() is a better place for it.


// FuzzConfig represents a set of parameters passed to the fuzz step.
type FuzzConfig struct {
Suffix string `json:"suffix"` // E.g. KASAN.
Copy link
Collaborator

@tarasmadan tarasmadan Sep 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Suffix" is how you use it.
I think something like "type" or "test_type" will improve the readability here.

Copy link
Collaborator

@tarasmadan tarasmadan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the part till "syz-cluster: prefix fuzzing-related steps" including it.

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.
Adjut the workflow template and the API to run multiple fuzzing
campaigns as a part of single patch series processing.
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.
It will help distinguish them once there are multiple ones.
During triage, process each fuzzing campaign separately as they may have
different base kernel revisions (e.g. if the newest revisions of the
kernel no longer build/boot under the specific kernel configuration).

Refactor the representation of the fuzzing targets in api.go.
Instead of just checking whether the bug was observed on the base crash,
accept a regexp of accepted bug titles as well.
Set up a KMSAN fuzzing campaign in parallel to KASAN for the net
patches.
Prefixes seem to distinguish the steps better than suffixes.
There's no reason to do first one and then another.
3G is not enough for kernels with KMSAN.
Slightly decrease the number of used VMs to fit into the available
CPUs/RAM.
KMSAN fails to boot when a specific q35 version is specified.
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.
We don't need it to hold it for the call to the externally supplied
callback.
There are still situations where we don't properly terminate fuzzing on
context cancelation.

Add more logging to debug it.
If a boot test step failed and we don't report the finding to the
dashboard, print the report/output to the console to facilitate
debugging.
Otherwise reproductions sometimes take almost all VMs.
@a-nogikh a-nogikh force-pushed the features/syz-cluster-kmsan branch from 364d86b to 7ee3357 Compare September 30, 2025 08:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants