SECT: Linux Concurrency Fuzzing

Overview

SECT turns Linux scheduling into a concurrency-testing resource: Syzkaller first finds useful syscall programs, then selected tasks run under domain-local temporal isolation while policies choose among eligible tasks. Instrumented scheduling points and admissibility checks make rare orderings more reachable without claiming exhaustive coverage or universal safety. The series explains the sched_ext control boundary, policy trade-offs, oracle roles, measured gains, throughput costs, and kernel-version limits.

Learning outcomes

SECT makes task order an explicit search dimension alongside syscall-input exploration.
Domain-local temporal isolation exposes ordered choices while preserving parallelism across test instances.
sched_ext provides a guarded dispatch boundary; it does not give BPF unrestricted control of the kernel.
Extra scheduling points and admissibility checks can improve reachability, but leave sampling, safety, completeness, and version limits.

Keywords

SECTsched_extConcurrencyFuzzingeBPFInterleavingTemporal isolationSyzkallerKCSANLinux

Chapters

SECT: Rare Kernel Interleavings

Why task order is a second fuzzing dimension

9 min · Why task order is a second fuzzing dimension

9 min

SECT: How sched_ext Schedules Tasks

Where BPF authority ends and kernel custody begins

11 min · Where BPF authority ends and kernel custody begins

11 min

SECT: Domain-Local Temporal Isolation

One active task per domain, not a global pause

8 min · One active task per domain, not a global pause

8 min

SECT: Controlled Scheduling Evidence

How policy, cost, safety, and oracles connect

7 min · How policy, cost, safety, and oracles connect

7 min

SECT: Choosing an Interleaving Policy

Random Walk, Random Priority, POS, or PCT?

8 min · Random Walk, Random Priority, POS, or PCT?

8 min

SECT: Instrumented Scheduling Points

More ordering visibility without preempting everywhere

8 min · More ordering visibility without preempting everywhere

8 min

SECT: Two Searches, Two Oracles

How inputs, schedules, and detectors divide the work

8 min · How inputs, schedules, and detectors divide the work

8 min

SECT: Evidence and Limits

When scheduler-guided exploration is worth the cost

9 min · When scheduler-guided exploration is worth the cost

9 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-8 Premium

FAQ

What problem does SECT solve in Linux concurrency testing?

SECT targets rare task interleavings that ordinary scheduling may fail to produce after an input reaches the relevant kernel code. It makes selected scheduling decisions programmable within a test domain.

How does SECT work with sched_ext?

sched_ext lets a BPF scheduler participate in CPU selection, enqueueing, dispatch, and task lifecycle while the scheduler core retains state and recovery authority. SECT uses that boundary for exploration.

Does SECT explore all Linux thread interleavings?

No. Its reach depends on domain membership, runnable tasks, instrumented and sampled scheduling points, admissibility checks, the active policy, and the kernel version. The result is bounded testing evidence, not exhaustive coverage.

What role does KCSAN play alongside SECT?

KCSAN observes sampled executions for evidence of data races and supported concurrency assertions, while SECT chooses task order. KCSAN cannot select the interleaving, and SECT does not classify every failure as a data race.