Two Searches, Two Oracles: The Fuzzing Loop Around SECT
SECT does not replace ordinary kernel fuzzing with a scheduler and call the result complete. It joins two searches: sequential fuzzing finds syscall programs that reach useful kernel behavior, and concurrency fuzzing turns selected programs into controlled interleaving experiments. This chapter follows one seed through that loop, then separates SECT’s role as a schedule explorer from KCSAN’s role as a sampled race detector. The distinction supports a practical judgment: a detector’s silence says little about an ordering bug if the execution never exposed the right ordering or the detector does not observe that class of failure.
From a promising input to a controlled concurrent test
The first phase is sequential input exploration. SECT builds on Syzkaller’s existing process for generating and mutating syscall sequences. Candidate calls are selected and appended, their parameters are instantiated, and the resulting program runs in its original order. When an execution covers previously unseen branches, the input is treated as promising and can be retained for further mutation. This phase answers a basic prerequisite for concurrency testing: does the input reach a meaningful part of the kernel at all?
That prerequisite is easy to undervalue. A schedule policy can create many different orders, but if every order runs a shallow or irrelevant input, the campaign has little chance of finding a useful failure. Sequential fuzzing supplies a corpus of programs that have already demonstrated some ability to exercise code. It searches the input space without imposing the full cost of schedule control on every execution.
The second phase starts from one of those seeds and applies a concurrency-specific mutation. SECT randomly selects a subset of syscalls from the sequence to execute concurrently. It duplicates the selected calls in a new program and marks the duplicates as asynchronous. The rest of the sequence remains structurally present, so the mutation can add concurrency opportunities without discarding the validity and setup relationships that made the original seed useful.
At execution time, a specialized Syzkaller-derived executor interprets the asynchronous annotations and creates dedicated threads for the selected calls. Those threads are assigned to the SCHED_EXT scheduling class and therefore become candidates for SECT’s temporal-isolation policy. Unannotated syscalls continue under the native scheduler. This selective boundary matters: the entire kernel does not enter a test-specific scheduling regime, and not every operation in the input pays the same scheduling cost.
Before controlled execution begins, the executor uses a synchronization barrier to align the participating tasks at a consistent starting state. Once the barrier is released, the selected tasks can reach injected or existing scheduling points, and SECT decides which eligible task receives the next opportunity. The policy can then cross-interleave the events of the asynchronous calls while surrounding work remains outside the controlled domain or follows the native scheduler.
The resulting execution has two kinds of feedback.