OS-Sanitizer: Finding Latent Defects Before Failure

Overview

OS-Sanitizer explores whether benign Linux runtime behavior can reveal latent defects before a visible failure. The series moves from defect-versus-failure distinctions to eBPF’s cross-layer event correlation, path analysis, coverage and workload costs, and case-study validation. Its central lesson is qualified: selected heuristics can expose context-dependent weaknesses and guide source review, reproduction, fuzzing, or testing, but they do not prove defects, replace static analysis, or cover unobserved executions.

Learning outcomes

OS-Sanitizer can infer possible latent defects from selected runtime behavior before a visible failure, but its reports are contextual leads, not proof.
eBPF connects selected user-space and kernel-space events through map-backed state; verifier safety does not establish application correctness.
The prototype offers targeted dynamic coverage and cannot replace static, language-level, or failure-based analysis or reveal unobserved executions.
System-interaction passes may be practical on some workloads, while hot userspace memory probes and repeated reports can impose substantial cost.

Keywords

OS-SanitizereBPFLinuxLatent defectsTOCTOUOwnershipPrivilegesHeuristicsFuzzingTesting

Chapters

OS-Sanitizer: When Nothing Goes Wrong

How context turns ordinary events into investigation leads

10 min · How context turns ordinary events into investigation leads

10 min

OS-Sanitizer: Defect, Fault, or Failure?

How evidence changes across the causal chain

9 min · How evidence changes across the causal chain

9 min

OS-Sanitizer: eBPF Event Correlation

How maps connect user space, kernel space, and reports

11 min · How maps connect user space, kernel space, and reports

11 min

OS-Sanitizer: From Event to Suspicion

How observation, inference, and validation stay separate

10 min · How observation, inference, and validation stay separate

10 min

OS-Sanitizer: Path Interception Signals

How ownership, timing, and privilege change a path

11 min · How ownership, timing, and privilege change a path

11 min

OS-Sanitizer: Coverage, Cost, and Alternatives

When runtime context justifies the overhead

13 min · When runtime context justifies the overhead

13 min

OS-Sanitizer: From Behavioral Smell to Finding

How reports lead to fixes, tests, or documented limits

12 min · How reports lead to fixes, tests, or documented limits

12 min

OS-Sanitizer: Contextual Leads, Not Proof

When eBPF adds value to software testing

13 min · When eBPF adds value to software testing

13 min

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

Plans

Ch.1-3 FreeCh.4-8 Premium

FAQ

What does OS-Sanitizer actually detect?

OS-Sanitizer detects selected runtime behavior patterns that match heuristics for possible Linux defects or code smells; it does not prove a vulnerability or failure.

How does eBPF help OS-Sanitizer find latent defects?

eBPF lets OS-Sanitizer observe selected user-space and kernel-space events, preserve their relationships in maps, and send contextual suspicions to userspace without modifying target applications.

Can OS-Sanitizer replace testing or static analysis?

No. OS-Sanitizer complements testing and static analysis by supplying live system context, while source-only properties and unobserved executions require other methods.

When is OS-Sanitizer practical to run?

OS-Sanitizer is most practical when live, cross-layer context matters and monitored hooks are not too hot; system-interaction passes may suit passive use, whereas some memory-function probes are costly.