A Working Model: From Event to Suspicion

OS-Sanitizer becomes easier to judge when its pieces are treated as one evidence chain rather than as a collection of eBPF features. This checkpoint connects the runtime event, the context preserved around it, the heuristic that interprets it, and the human investigation that follows. The useful capability is not merely to collect more data; it is to know which parts of a report are observed, which are inferred, and which still need to be established.

A runtime signal is a chain, not a point

Imagine an application performing an operation that looks ordinary on its own. A single hook can tell us that a function was entered or that the kernel began handling a request. That fact is real, but it may be too thin to answer the question OS-Sanitizer cares about: does this behavior, in this surrounding context, resemble a latent defect?

The answer is assembled over time. One observation may capture the application’s request. A later observation may expose how the kernel resolved it or which security-relevant condition accompanied it. State stored in an eBPF map connects those events. A heuristic examines the accumulated state and decides whether to emit a suspicion. A userspace launcher filters and formats the result so an investigator can inspect it.

This sequence can be understood as six roles:

  • The application produces the behavior being examined.
  • An attachment point supplies the moment at which an eBPF program can observe it.
  • Map-backed state preserves the relationship among observations that arrive at different points.
  • The heuristic interprets the relationship as a possible defect pattern or code smell.
  • The launcher applies presentation and filtering decisions outside the kernel.
  • The investigator decides what the signal means in the application’s actual context.

These roles own different kinds of state. The application owns its requested operation and its own intended behavior. The eBPF programs collect event facts within the safety limits imposed on them. The map holds temporary contextual state, which must be associated with the right operation and cleared when it is no longer valid. The launcher owns much of the report’s format and severity policy. The investigator owns the final judgment.

sequenceDiagram participant App as Linux application participant Verifier as eBPF verifier participant Hook as eBPF attachment participant Map as Map-backed state participant Launcher as Userspace launcher participant Investigator as Investigator Verifier->>Hook: Permit a safe analysis program App->>Hook: Produce a runtime event Hook->>Map: Record initial context App->>Hook: Produce a related later event Hook->>Map: Enrich or close the observation Map-->>Hook: Return accumulated context Hook->>Launcher: Emit a suspected pattern Launcher->>Launcher: Filter and format the report Launcher->>Investigator: Present readable evidence Investigator->>Investigator: Review, reproduce, or test

The verifier appears at the beginning because it controls the observer, not the application. It can reject an analysis program that reads an invalid pointer, uses uninitialized state, or otherwise violates the conditions required for safe in-kernel execution. It does not decide whether the application has kept a promise to its users.