Prototype for the new syz-verifier using the new rpcserver and fuzzer #6292

dBransky · 2025-08-15T22:30:13Z

No description provided.

google-cla · 2025-08-15T22:30:54Z

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

dBransky · 2025-08-20T16:21:25Z

@a-nogikh any chance to review?

a-nogikh · 2025-08-20T21:52:18Z

I've skimmed through, but haven't prepared the comments yet. Will take care of it tomorrow.

a-nogikh

This looks like the totally right direction, thanks for taking the time to resurrect the tool!

syz-verifier/verifier.go

syz-verifier/main.go

syz-verifier/verifier.go

dBransky · 2025-12-07T16:39:47Z

@a-nogikh and @dvyukov
Please see the updated PR, all comments fixed and missing features in the verifier were added.
I think that the current version is OK as an MVP

a-nogikh

(first pass, there's a lot of code)

a-nogikh · 2025-12-22T12:20:53Z

syz-manager/manager.go

+		},
 	}
-
 	mgr.corpusDBMu.Lock()


Let's move locking to the top of the function.

a-nogikh · 2025-12-22T12:22:49Z

pkg/manager/corpus.go

Please extract the CorpusMinimizer refactoring changes into a separate commit. We'll likely merge it first (as a separate PR) to reduce the overall code diff here.

a-nogikh · 2025-12-22T12:26:47Z

pkg/manager/corpus.go

+	// During corpus triage it would happen very often since we are actively adding inputs,
+	// and presumably the persistent corpus was reasonably minimal, and we don't use it for fuzzing yet.
+	if cm.PhaseCheck != nil && !cm.PhaseCheck() {
+		return cm.LastMinCorpus


Instead of taking and returning cm.LastMinCorpus value over and over again, let's just return error from Minimize() (instead of doing log.Fatalf here). Or return nothing and keep the log.Fatalf.

The caller can always determine the latest corpus size anyway.

a-nogikh · 2025-12-22T12:28:06Z

pkg/manager/corpus.go

+	LastMinCorpus  int
+	SaturatedCalls map[string]bool
+	DisabledHashes map[string]struct{}
+	PhaseCheck     func() bool // returns true if we should proceed with minimization


Let's keep this logic on the caller side. We don't really gain anything with this callback here.

a-nogikh · 2025-12-22T12:32:13Z

syz-verifier/README.md

+
+## Development Status
+
+This is a **prototype** showcasing the verifier design with:


Nit: the style is a bit too ChatGPT, especially below :)

Let's keep it in line with other syzkaller docs.

a-nogikh · 2025-12-22T13:29:07Z

syz-verifier/verifier.go

 }
+func (vrf *Verifier) fuzzingLoop(ctx context.Context) {
+	log.Logf(0, "starting fuzzing loop")
+	select {


It looks like we're getting here almost immediately, so there's no reason to do such a select at the beginning of the function.

Much better to transform other potentially blocking operations into a select block, e.g. enabledSyscalls := <-kernel.enabledSyscalls below.

a-nogikh · 2025-12-22T13:31:19Z

syz-verifier/verifier.go

 	}
-	return
 }
+func (vrf *Verifier) fuzzingLoop(ctx context.Context) {


This function is already huge, and, judging by TODOs, it's going to become even bigger over time. Please split it.

Just a thought - maybe we want to split out the verifier logic into some class in pkg/fuzzer? Or create pkg/verifier?

Comparison of several execution results should definitely be extracted somewhere - we'll also need it later when we get to the generation of reproducers.

a-nogikh · 2025-12-22T13:38:53Z

syz-verifier/verifier.go

+	"golang.org/x/sync/errgroup"
+)
+
+// Constants for kernel phases


I wonder if these phases are actually simplifying the implementation here.

You seem to be already incorporating the steps sequence in your code and synchronizing it via channels.

Will it be bette if we get rid of them completely here?

a-nogikh · 2025-12-22T13:42:31Z

syz-verifier/verifier.go

+		// This enables coverage-guided fuzzing
+		feedbackResult := responses[0]
+		if feedbackResult == nil {
+			// If kernel 0 failed, try to find any successful result


If the kernels are different (and we must assume that they are different here in syz-verifier), we should not mix resulting coverage feedback from them. It breaks all assumptions of the fuzzer.

a-nogikh · 2025-12-22T13:45:22Z

syz-verifier/verifier.go

+		kernel.http.Corpus.Store(kernel.corpus)
 	}
+	// TODO: Aggregate to main HTTP server instead of per-kernel
+	if kernel.cfg.Snapshot {


The rest of the code does not support the snapshot mode, so let's not include this logic here at all.

This commit removes the old syz-verifier's rpcserver, executor, stats, monitor and utils as we are going to rewrite the verifier to use the new rpcserver and executor. Part of the fix for issue: google#5976

…uzzer This commit introduces a prototype for the new syz-verifier using the new rpcserver and fuzzer. An in-depth explanation is available in README.md. Remaining work includes connecting the reproduction loop, HTTP servers, enabling snapshots, and the comparison phase. The prototype already implements a working differential fuzzing loop.

…d improve verifier Extract corpus minimization logic into shared pkg/manager/corpus.go for reuse by both syz-manager and syz-verifier. Improve syz-verifier fuzzing implementation: - Update request distribution strategy for better workload management - Change result comparison logic to more accurately detect mismatches - Print mismatches in more readable format for easier debugging - Enforce restarting executor between program executions to avoid state pollution - Fix coverage-guided fuzzing to properly track code coverage - Fix maxSignal phase management for accurate signal tracking - Simplify crash handling logic - Refactor corpus management to use single goroutine with one channel Enhance HTTP server monitoring: - Add log, coverage statistics, and VM information to HTTP server views - Enable HTTP server logging for better observability Fix race condition where multiple executor goroutines call MaxSignal() simultaneously from RPC server connection loops.

This commit fixes 2 small bugs founded: - wrong use of kernel.runInstance() function - the return values of the function has been changed in the master branch so we had to update our calls to the function - Fix wrong print of call.Flags

Split the large fuzzingLoop function into focused helpers to improve readability and maintainability: - fetchNextRequest: handle request retrieval with context cancellation - isDistributableRequest: check if request should be compared across kernels - buildRequestCopies: construct kernel-specific request copies with callbacks - dispatchAndCollect: submit requests to all kernels and collect results The main fuzzing loop is now cleaner with clear separation of concerns: fetch → filter → build → dispatch → feedback → compare. No functional changes, purely refactoring for code clarity.

…o kernel comparison tool for pre-learned corpus. No longer learns or generates programs. Instead: - Takes existing saturated corpus.db as input (-corpus flag) - Executes each program across multiple kernel versions in parallel - Compares syscall errno per call to detect behavioral differences - Logs mismatches with full program sequence and call-by-call results

dBransky · 2026-01-13T12:09:46Z

@a-nogikh, @dvyukov and @tarasmadan
Please review updated PR

dvyukov requested a review from a-nogikh August 15, 2025 22:33

a-nogikh reviewed Aug 21, 2025

View reviewed changes

tarasmadan mentioned this pull request Sep 3, 2025

syzbot: cover more configurations #6351

Open

dBransky force-pushed the verifier-dev branch 6 times, most recently from 6ed977b to 0d8642c Compare December 7, 2025 13:59

dBransky requested review from avagin and blackgnezdo as code owners December 7, 2025 15:52

dBransky force-pushed the verifier-dev branch 4 times, most recently from b68ac08 to 5376734 Compare December 7, 2025 16:26

dBransky requested review from a-nogikh, dvyukov and tarasmadan December 9, 2025 08:18

a-nogikh removed request for avagin and blackgnezdo December 22, 2025 12:12

a-nogikh reviewed Dec 22, 2025

View reviewed changes

dBransky and others added 5 commits January 13, 2026 13:57

syz-verifier: remove old rpc server, executor, monitor and stats

f3fc079

This commit removes the old syz-verifier's rpcserver, executor, stats, monitor and utils as we are going to rewrite the verifier to use the new rpcserver and executor. Part of the fix for issue: google#5976

dBransky force-pushed the verifier-dev branch 2 times, most recently from 84d9b9d to a1a73a9 Compare January 13, 2026 12:07


		## Development Status

		This is a prototype showcasing the verifier design with:

Prototype for the new syz-verifier using the new rpcserver and fuzzer #6292

Are you sure you want to change the base?

Prototype for the new syz-verifier using the new rpcserver and fuzzer #6292

Uh oh!

Conversation

dBransky commented Aug 15, 2025

Uh oh!

google-cla bot commented Aug 15, 2025

Uh oh!

dBransky commented Aug 20, 2025

Uh oh!

a-nogikh commented Aug 20, 2025

Uh oh!

a-nogikh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dBransky commented Dec 7, 2025

Uh oh!

a-nogikh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dBransky commented Jan 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants