vbpf / prevail / 26218991840

86%

push

github

Thread stack cell registry through AnalysisContext (#1116)

The array-domain cell map -- per-DataKind tracking of which stack cells
the analysis currently maintains a symbolic variable for -- previously
lived in a thread-local LazyAllocator and was cleared between analyses
via clear_thread_local_state(). That was fragile: if anything built an
ArrayDomain (e.g. an entry invariant) and then re-cleared the map, the
domain's cells became orphaned and subsequent stack ops silently saw an
empty map.

Move the registry to AnalysisContext as a unique_ptr-owned
StackCellRegistry (with a custom deleter so the header only needs a
forward declaration). All ArrayDomain methods that touch the cell map
now take StackCellRegistry& explicitly; the call sites in
ebpf_transformer.cpp and ebpf_domain.cpp pass context.cells(). The
registry dies with the context, so no global clear is required and
nested or sequenced analyses can no longer interfere.

ebpf_verifier_clear_thread_local_state() now only clears SplitDBM's
transient scratch buffer; the array map is no longer thread-local.

Reusing an AnalysisContext across analyze() calls would carry
stale stack-cell entries from the previous run, since the registry now
lives on the context rather than in thread-local state. clear it at the
top of both analyze(context) overloads (the StringInvariant-entry one
and the default-entry one); each then re-populates the registry as part
of building the entry domain.

The caller-supplied EbpfDomain overload still skips the clear -- by the
time it runs the caller has already populated the registry through the
entry's stack initialization. 

Signed-off-by: Elazar Gershuni <elazarg@gmail.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

83 of 84 new or added lines in 5 files covered. (98.81%)

9337 of 10776 relevant lines covered (86.65%)

6270935.12 hits per line