{"id":"05ae0d9a-7358-499f-b9e6-1c8fadebe4b5","arxiv_id":"2608.11418","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A systematic comparison of kernel telemetry capture for provenance finds eBPF LSM programs the most efficient, while most provenance systems lose 90-100% of logs and fail security requirements.","lead":"This paper studies how Linux can capture kernel telemetry for security provenance, finding eBPF with LSM hooks the most promising approach. It then benchmarks eight provenance systems and five capture agents, concluding that most drop most logs and cannot guarantee integrity or availability.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"LSM 'single attachment' captures LSM authorization, not final operation success; the efficiency advantage in §4.2 rests on conflating these two verdicts.","rationale":"The reader's weakest_assumption identifies exactly the same load-bearing concern: Section 4.2 treats an LSM hook firing as the operation's verdict, although the kernel operation can fail after the hook. This is the most central issue because the paper's forward-looking recommendation — that LSM programs are the best capture basis for provenance — rests on the measured efficiency advantage, and that advantage depends on the single-attachment claim. If the claim is false, the recommendation may still hold for other reasons (stable ABI, cgroup pre-filtering, TOCTOU resistance), but the empirical support is weakened. The concern is concrete and testable, and it is a matter of internal consistency: the paper explicitly wants to exclude attempted-but-failed operations, yet LSM-only capture cannot distinguish them from completed ones. I also considered the macro-benchmark log-loss metric, which may conflate modeling granularity with actual dropped events, but that issue is more diffuse and the paper's qualitative classification would survive even a partial correction. The LSM verdict conflation directly invalidates a specific quantitative comparison. The paper can be conditionally accepted: the survey and classification stand, but the benchmark claims need qualification and an additional experiment to show LSM overhead after true verdict capture. Hence no change to the reader's CONDITIONAL verdict.","tokens_in":15281,"tokens_out":6060,"duration_ms":60438,"concrete_test":"Run the file workload on the same kernel with two cooperating instruments: an LSM eBPF program attached to inode_init_security, and a syscall-exit kprobe (or tracepoint) on openat/openat2 returning success for the same creation operations. Match events by PID and filename (or by a per-task marker) and count LSM firings that have no corresponding successful creation. If any such mismatches occur, re-run the §4.2 overhead comparison with an LSM program that also captures completion (e.g., a return probe on the file-creation path) and compare its overhead against the dual-attachment tracing/kprobe configurations. If LSM with true-verdict capture is no longer the cheapest across all workloads, the single-attachment efficiency conclusion is unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.2's central efficiency claim is that 'Only LSM programs obtain both [arguments and verdict] with a single attachment: registered last in the chain, they execute only for operations allowed by all other LSMs.' This equates passing the LSM chain with the operation actually occurring. But an LSM hook fires inside the security-check path, before the kernel operation has committed. For the benchmarked hooks this is concrete: inode_init_security runs during inode creation, but the file creation can still fail afterwards (e.g., ENOSPC during block allocation); socket_accept can be followed by failure to allocate a file descriptor (EMFILE); task_alloc can be followed by memory-allocation failure in copy_process. The paper itself states the provenance criterion in the same section: 'a provenance graph must contain only the causal events that actually occurred.' An LSM-only record is an authorization event, not a completion event, so it does not meet that criterion. Consequently, the Figure 1 comparison is not apples-to-apples: LSM single-attachment captures a weaker semantic event than the dual-attachment entry+exit instrumentation used for tracepoint, kprobe, and tracing, which discards operations that were ultimately rejected or failed. The claimed single-attachment advantage is therefore partly an artifact of capturing less information. The paper applies the 'may still be denied' concern to system-call entry but not to LSM hooks, an internal inconsistency. If LSM programs must also verify final success, their overhead would increase and the headline 'LSM programs emerge as the best suited' is weakened.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies Linux kernel telemetry capture for security-oriented provenance. It classifies capture approaches (ptrace, filesystem snapshots, integrated systems, out-of-tree modules, eBPF), benchmarks four eBPF program types (tracepoint, kprobe, tracing, LSM) and three filtering granularities (pre/in/post) under three workloads, and classifies eight provenance systems and five capture agents, macro-benchmarking the open-source subset. The paper concludes that eBPF LSM programs are the best capture basis, citing single-attachment capture of arguments and verdict, cgroup prefiltering, stable interfaces, and TOCTOU resistance, and that most provenance systems suffer 90-100% event loss, making them unsuitable for security use cases.","tokens_in":15507,"tokens_out":5289,"duration_ms":46734,"significance":"If the results hold, this is a useful comparative study: it systematizes capture-layer options, gives a reproducible microbenchmark harness across eBPF program types and filtering strategies, and quantifies event loss of real provenance systems. The TOCTOU analysis in Section 3.3 is a valuable contribution, and the classification tables in Section 5.3 are a practical reference for system builders. However, the central comparison rests on an interpretation of LSM single-attachment semantics that needs correction, and key measurements lack uncertainty quantification. With those points addressed, the paper would be a solid reference for kernel-telemetry provenance research.","major_comments":[{"comment":"The central efficiency claim that LSM programs obtain 'arguments and verdict with a single attachment' equates passing the LSM chain with the operation's final success. An LSM hook fires during the security-check path, before the protected operation commits. For the benchmarked hooks this is concrete: inode_init_security runs during inode creation but the file creation can still fail afterwards (e.g., ENOSPC during block allocation); socket_accept can be followed by failure to allocate a file descriptor (EMFILE); task_alloc can be followed by memory-allocation failure in copy_process. The paper's own provenance criterion in the same section states that 'a provenance graph must contain only the causal events that actually occurred.' An LSM-only record is an authorization event, not a completion event, so the Figure 1 comparison is not apples-to-apples: dual-attachment tracepoint/kprobe/tracing instrumentation discards rejected or failed operations, while the LSM program records them. The claimed single-attachment advantage is therefore partly an artifact of capturing weaker semantics. The authors should either demonstrate that post-hook failures are negligible for the chosen hooks (with failure-injection or error-path measurements), or reframe the LSM capture as authorization-event provenance, or instrument exits via kprobes for a fair comparison.","section":"Section 4.2, Table 4"},{"comment":"The microbenchmark's central quantitative claims are made without uncertainty estimates. Section 4.1 says values are 'averaged over 10 runs after 10 warm-up iterations,' and Figure 1 reports overheads that differ by less than 0.1 percentage points in the key comparison (LSM 1.13% vs. tracing 1.22% for the network workload at the LSM location after verdict capture). The text says the entry-only gap between LSM and tracing is 'negligible given the variance,' but no variance, confidence interval, or per-run distribution is reported. Without such information, the conclusion that LSM programs are 'the most efficient for provenance capture' is not statistically supported, and the conclusion that LSM is cheaper than tracing after verdict capture rests on a 0.09-point gap. Please report per-run values or confidence intervals, state whether the differences are statistically significant, and adjust the claims accordingly.","section":"Section 4.1, Section 4.2, Figure 1"},{"comment":"The macro benchmark's log-loss metric is computed as (1 - n_traced / n_expected) x 100 for a single witness event per workload (e.g., 50k clone events for the process workload), while each tool runs on a separate Fedora 35 VM 'keeping each system's defaults.' This conflates a tool's intentional capture scope (ConProv instruments only 9 interfaces; eAudit emits a raw stream without graph reconstruction) with failure to meet the workload's ground truth. To support the strong claim that 'most unable to guarantee event integrity and availability,' the authors should either configure each system to a common, security-relevant minimum event set justified against the witness events, or demonstrate that the witness events are mandatory for the stated security use cases, and should quantify VM-to-VM variability. The current '90 to 100% loss' statement is therefore not yet fully supported as a claim about capture-layer failure.","section":"Section 5.1, Figure 3"}],"minor_comments":[{"comment":"In the abstract, 'thesetoolsare built' is missing a space between 'these' and 'tools'; please fix the LaTeX spacing.","section":"Abstract"},{"comment":"Figure 1's x-axis annotations ('100k 200k ...') are difficult to read and the caption does not clearly explain the mapping of those counts to eBPF program executions per workload; please clarify.","section":"Figure 1"},{"comment":"The name 'SPADE' in Figure 3 is written as 'Spade' in Table 5 and the text; please unify the capitalization.","section":"Figure 3 and Table 5"},{"comment":"The terms 'prefiltering', 'pre filtering', and 'pre' are used inconsistently; please standardize the terminology.","section":"Section 4.3"}],"recommendation":"major_revision","confidential_remarks":"The paper has a solid empirical core and a useful survey, but the central LSM 'verdict' claim is an overstatement that should be resolved before acceptance. I would ask for either failure-path measurements for the benchmarked LSM hooks or a clear redefinition of what semantic event LSM single-attachment capture records. The missing error bars are also a blocking issue for the headline efficiency claims. The macro-benchmark methodology should be tightened or its conclusions softened. If these points are addressed in a revision, the paper would be a valuable contribution to the provenance systems literature."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is the first paper I've seen that treats the provenance capture layer as an engineering choice rather than a given, and that framing pays off. The classification of eight provenance systems and five capture agents by capture approach and filtering mode is careful and will be a useful reference. The eBPF microbenchmarks tell a coherent story: trampoline-based tracing beats tracepoint beats kprobe for entry-only capture; the exit attachment roughly doubles per-event work; cgroup pre-filtering is the cheapest route to container granularity. The TOCTOU analysis (69% of system calls take user-space pointers) is solid, and the macro-benchmark finding that most open-source graph-building systems lose 90-100% of expected events under default configs deserves attention even with caveats.\n\nThe main soft spot is real, and the stress-test note on verdict conflation holds up on reading. Section 4.2 claims an LSM program registered last in the chain captures arguments and verdict with one attachment, yielding the same semantic event as entry+exit for the other program types. It doesn't. inode_init_security fires during inode creation, but creation can still fail (ENOSPC in block allocation); socket_accept can be followed by EMFILE on fd allocation; task_alloc can be followed by allocation failure in copy_process. The paper itself says a provenance graph must contain only events that actually occurred, and applies the 'may still be denied' concern to system-call entry but not to LSM hooks. So the single-attachment LSM program records a weaker event, and Figure 1 compares different semantics. This doesn't sink the paper: for these workloads, post-LSM failures are presumably rare, and the cgroup pre-filtering advantage stands. But the efficiency edge is partly an artifact of recording less, and the paper should say how often the LSM event and the completed operation diverge, or add a second attachment to verify.\n\nSecond, no error bars. Ten runs with fixed P-states, but no variance reported anywhere, despite a prose gesture at 'variance.' For a paper whose punchline is quantitative, that is a real gap. Third, no artifact release; the 90-100% log-loss numbers would be far more credible with code and data linked.\n\nMinor quibble: the macro benchmark keeps each tool's defaults on separate Fedora 35 VMs, which is defensible given patched kernels, but 'log loss' conflates events dropped with events the default config never captures. The conclusion that most systems are 'unsuitable for security use cases' is broader than this snapshot supports.\n\nWho this is for: provenance researchers and eBPF tool builders; it will be a reference point. My recommendation: send to peer review, require major revision covering the verdict conflation, error bars, and artifact release. I'd engage as a skeptical referee.","headline":"First systematic capture-layer comparison for provenance, genuinely useful, but the LSM single-attachment edge conflates authorization with operation success; quantitative claims need error bars, artifacts, and rework before they stand.","tokens_in":16088,"tokens_out":7320,"would_cite":true,"duration_ms":59655,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Security provenance tools drop 90-100% of kernel events","keywords":["provenance","kernel telemetry","eBPF","LSM","cgroup filtering","TOCTOU","container security","Linux audit"],"falsifier":"Run the benchmark file-creation workload on a filesystem configured to fail with ENOSPC after the inode security initialization hook, then compare the count of recorded LSM events against the actual number of files created; a surplus of recorded events over created files would show that single-attachment capture records attempted operations as if they succeeded.","tokens_in":15065,"feed_emoji":"🐧","tokens_out":7944,"duration_ms":96296,"temperature":0.7,"pith_summary":"The paper sets out to determine which Linux kernel telemetry mechanism should carry security-oriented provenance capture, and it argues that eBPF programs attached to Linux Security Module (LSM) hooks are the best choice. Benchmarks across network, file, and process workloads show that LSM programs record both an operation's arguments and its verdict with a single attachment, while tracepoint, kprobe, and tracing programs must instrument entry and exit and roughly double their per-event cost. Adding cgroup attachment lets LSM programs pre-filter events so they only run for the traced container, the cheapest of the three filtering methods. The paper then classifies eight provenance systems and five capture agents, and macro-benchmarks the open-source subset: most graph-building systems lose 90 to 100 percent of expected events, and no system combines low overhead, no log loss, and actual graph construction. If correct, current provenance systems are not ready for security use, and future capture layers should be built on LSM-based eBPF with cgroup pre-filtering.","feed_headline":"Security provenance tools drop 90-100% of kernel events","feed_subtitle":"Syscall tracing roughly doubles per-event cost and stays vulnerable to TOCTOU races; LSM capture does not.","key_machinery":"The central object is the eBPF LSM program attached to a Linux Security Module interface (the LSM_MAC attach type, optionally restricted to a cgroup via LSM_CGROUP), dispatched through a BPF trampoline. Because it sits at the end of the LSM chain, it fires only after every other LSM has allowed the operation, so one hook instance carries both the arguments and the verdict at a single attachment. The same mechanism's cgroup flavor enables pre-filtering, in which the kernel skips the program entirely for events outside the traced container, avoiding the per-event cost of in-program or user-space filtering. The comparison machinery is the micro-benchmark that separates entry attachment cost from exit attachment cost, making visible the roughly doubled per-event overhead that non-LSM program types incur once the verdict is captured.","core_discovery":"Using the ability to record a MAC operation's arguments together with its final verdict in a single LSM hook firing as the key efficiency test, the paper shows that LSM eBPF programs beat tracepoint, kprobe, and tracing programs on every workload once verdict capture is required. It also shows that cgroup-attached LSM programs, which the kernel only triggers for events in the target cgroup, outperform in-program and post-hoc filtering across all workloads. Measured against the set of benchmarked open-source tools, the paper finds that the systems that build provenance graphs all suffer roughly 90-100 percent log loss in most workloads, while the one system that avoids loss emits a raw edge stream and never constructs a graph. The paper concludes that provenance systems currently rely on capture layers that cannot guarantee event integrity and availability, and that LSM interfaces, which expose kernel-object life cycles over a smaller hook surface than system calls, are the most suitable basis for security-oriented provenance capture.","pith_inferences":["We infer that LSM-only capture, if the completeness gaps found for older kernels persist, would miss information flows through pipes, splice, and shared memory; comparing an LSM-hook trace against a system-call trace on one workload would decide this.","We infer that the cgroup pre-filtering advantage generalizes to other granularities such as pods, processes, or users, since the same BPF link mechanism can attach to different cgroup or namespace scopes; the paper only measures containers.","We infer that the single-attachment verdict claim can be stress-tested by injecting late kernel failures after the LSM hook; if recorded events exceed actual completions, the claimed equivalence between hook firing and operation success would be weakened.","We infer that combining the low-loss edge-stream design with LSM capture could produce a graph-building system that is both efficient and complete; the paper does not benchmark this combination, so it remains an open testable direction."],"forward_implications":["LSM eBPF programs with cgroup attachment should form the capture basis for new provenance systems, because they are the only measured configuration that combines single-attachment verdict capture, stable interfaces, and pre-filtering overhead.","Every non-LSM eBPF program type must hook both entry and exit to discard denied operations, roughly doubling per-event cost; any system-call trace that omits exit events records attempts as if they were successes.","Because all benchmarked graph-building systems lose 90 to 100 percent of expected events in most workloads, their provenance graphs are heavily incomplete, so security analyses built on them inherit that incompleteness.","The one lossless system's raw edge stream avoids graph construction entirely, showing that low overhead and completeness are achievable together only when graph modeling is abandoned; reconciling them remains unsolved.","The maintained, portable capture agents are better building blocks for future provenance capture than the unmaintained research systems, despite their own overhead and log loss."],"supporting_citations":[{"why":"Supplies the concept of pre-filtering, where events are discarded before the eBPF program triggers, which the paper applies to cgroup attachment.","marker":"[8]"},{"why":"Documents the per-cgroup LSM flavor in the Linux kernel, the mechanism that makes pre-filtered container-granular capture possible.","marker":"[13]"},{"why":"Demonstrates TOCTOU race attacks against system-call tracing, the robustness threat that LSM hooks avoid by inspecting kernel-copied arguments.","marker":"[17]"},{"why":"Supports the claim that LSM interfaces are more stable than kprobe or tracing interfaces across kernel versions.","marker":"[19]"},{"why":"Provides compile-time verification of which system-call paths reach LSM interfaces, the basis for the paper's open question about LSM completeness.","marker":"[15, 16]"},{"why":"Provides the auditd-based system whose 91-99 percent log loss anchors the finding that syscall-capture systems lose most logs.","marker":"[14]"},{"why":"Example of cgroup-attached LSM capture through a patched kernel; the paper benchmarks its log loss.","marker":"[28]"},{"why":"Example of LSM-based whole-system capture; the paper benchmarks its high overhead and log loss.","marker":"[31]"},{"why":"Tracepoint-based system that loses no logs; establishes that low loss is achievable with a raw edge stream.","marker":"[34]"},{"why":"Kprobe/tracepoint container-aware system whose near-total log loss illustrates syscall-subset capture loss.","marker":"[10]"}],"fun_headline_variants":["Provenance tools lose 90-100% of kernel events","LSM eBPF beats tracepoints for provenance capture","Cgroup LSM programs cut provenance capture cost","Kernel telemetry study finds LSM best for provenance","Provenance capture: LSM eBPF wins on overhead"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing assumption is that an LSM hook firing after all other LSMs have allowed an operation counts as that operation having actually succeeded; in reality the kernel operation can still fail later, so some recorded events may not correspond to real events.","fun_headline_variants_meta":{"raw":{"variants":["Provenance tools lose 90-100% of kernel events","LSM eBPF beats tracepoints for provenance capture","Cgroup LSM programs cut provenance capture cost","Kernel telemetry study finds LSM best for provenance","Provenance capture: LSM eBPF wins on overhead"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000377,"raw_usage":{"total_tokens":1979,"prompt_tokens":886,"completion_tokens":1093,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":502,"completion_tokens_details":{"reasoning_tokens":1010}},"tokens_in":502,"tokens_out":1093,"duration_ms":10146,"temperature":1.0,"reasoning_tokens":1010,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T14:12:04.832496+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the benchmark file-creation workload on a filesystem configured to fail with ENOSPC after the inode security initialization hook, then compare the count of recorded LSM events against the actual number of files created; a surplus of recorded events over created files would show that single-attachment capture records attempted operations as if they succeeded.","supporting_citations":[{"cited_title":"Eliminating eBPF Tracing Overhead on Untraced Processes","cited_arxiv_id":null,"evidence_quote":"Supplies the concept of pre-filtering, where events are discarded before the eBPF program triggers, which the paper applies to cgroup attachment."},{"cited_title":"bpf: per-cgroup lsm flavor","cited_arxiv_id":null,"evidence_quote":"Documents the per-cgroup LSM flavor in the Linux kernel, the mechanism that makes pre-filtered container-granular capture possible."},{"cited_title":"Trace Me If You can: BypassingLinux Syscall Tracing, 2022","cited_arxiv_id":null,"evidence_quote":"Demonstrates TOCTOU race attacks against system-call tracing, the robustness threat that LSM hooks avoid by inspecting kernel-copied arguments."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supports the claim that LSM interfaces are more stable than kprobe or tracing interfaces across kernel versions."},{"cited_title":"Spade: Support for provenance auditing in distributed environments","cited_arxiv_id":null,"evidence_quote":"Provides the auditd-based system whose 91-99 percent log loss anchors the finding that syscall-capture systems lose most logs."},{"cited_title":"Secure Namespaced Kernel Audit for Containers","cited_arxiv_id":null,"evidence_quote":"Example of cgroup-attached LSM capture through a patched kernel; the paper benchmarks its log loss."},{"cited_title":"Practical whole-system provenance capture","cited_arxiv_id":null,"evidence_quote":"Example of LSM-based whole-system capture; the paper benchmarks its high overhead and log loss."},{"cited_title":"Sekar, Hanke Kimm, and Rohit Aich","cited_arxiv_id":null,"evidence_quote":"Tracepoint-based system that loses no logs; establishes that low loss is achievable with a raw edge stream."},{"cited_title":"ConProv: AContainer- Aware Provenance System for Attack Investigation","cited_arxiv_id":null,"evidence_quote":"Kprobe/tracepoint container-aware system whose near-total log loss illustrates syscall-subset capture loss."}],"review_version":1}