The Boundary of the Lens: Coverage, Cost, and Alternatives

OS-Sanitizer has shown how one carefully chosen runtime signal can expose a hidden relationship between an application and the Linux system around it. The harder judgment is deciding how far that advantage extends. This chapter examines the prototype’s coverage, its structural blind spots, its workload-shaped costs, and the conditions under which eBPF adds evidence that another method would miss. The result is not a ranking with one universal winner, but a way to match an evidence question to an observation strategy.

Coverage is a set of questions, not a score

OS-Sanitizer is organized as a collection of passes. Each pass targets a recognizable behavior pattern and may contain programs that report a suspicious region, enrich its context, clear stale state, or filter a known false positive. That structure is important because it makes the prototype extensible, but it also sets a firm boundary: a pass can recognize the pattern it was designed to express, not every defect that happens to share a broad category.

The paper groups its passes into four families. The first concerns fault-prone interactions with the operating system, such as using a file-related check before an opening operation, creating overlapping mappings, or requesting memory with read, write, and execute permissions at the same time. The second concerns fault-prone use of library functions, including unsafe interfaces and mutable data passed into places where it may acquire special meaning. The third covers environmental defects, where the program’s behavior becomes unsafe because of file permissions or path ownership around it. The fourth focuses on memory-manipulating functions whose input-dependent copy sizes can indicate a buffer-safety problem.

These families span different boundaries. Some ask whether an application interacts incorrectly with the kernel. Some ask whether it uses a library interface in a risky way. Some ask whether the environment can turn a normal operation into a security problem. Others inspect low-level calls whose danger depends on the relationship between a source size and a destination. The breadth is meaningful because the same system vantage point can support different questions, but the questions are not interchangeable.

A pass therefore produces selected coverage rather than a general safety score. It may observe a relevant event but lack the context needed to classify it. It may have no attachment point for a source-only property. It may identify a pattern that is appropriate for one caller and intended for another. The prototype’s results support the feasibility of these targeted heuristics; they do not establish complete coverage of software weakness classes or a universal false-negative rate.

Hard limits and soft costs are different problems

Some limits are structural. eBPF is a dynamic mechanism attached to a running Linux system, so it cannot perform static analysis by itself. If the question is whether a source property holds in every possible path, runtime observation alone cannot answer it. It can report what happened in the executions that reached the available observation points.

Language boundaries create another hard limit. OS-Sanitizer can observe that a Java application interacts with the filesystem, but the prototype cannot necessarily attach to Java-level API misuse in the same way it can observe functions in a native executable. The system interaction remains visible; the higher-level language semantics may not be. That is not a tuning issue that more filtering can solve. It calls for another analysis strategy or a different attachment layer.