【Falco】libscap：捕获会话与 API/Schema 协商
内容提要
本文介绍Falco 0.44.1中libscap的职责：与内核驱动通信、打开会话、读取ring缓冲、协商API/Schema版本。0.44与0.43不兼容，需成对升级驱动。scap-open仅验证原始事件捕获，不涉及规则引擎。排障时先查协商是否成功，再查规则，避免误判。
延伸解读
版本协商是启动硬门槛
libscap 打开会话时必须与驱动协商 API 与 Schema 版本，二者分别约束通信机制和事件类型布局。0.44 对两者同时 major bump，导致 0.43 驱动与 0.44 用户态不兼容，错配会表现为协商失败或无法使用驱动，而非规则问题。排障时应先核对 API/Schema 行是否与 10.2.0+driver 对齐，再谈规则。
scap-open 只验证原始捕获
scap-open 用于验证驱动是否产出 scap 编码事件，属于 libscap 边界内的工具。它能证明驱动和捕获层工作正常，但不能证明规则引擎会告警。若 scap-open 有输出而 Falco 无告警，问题应定位在 libsinsp 富化或规则引擎，而非重装驱动。生产环境仍以 Falco 进程自身的协商结果为准。
双引擎在接口层分叉
modern_ebpf 与 kmod 在进入 libscap 后共享统一事件流，但在安装方式、通信机制和缓冲几何上不同：modern_ebpf 可动态注入探针，kmod 需预装 .ko；通信分别依赖 maps 和 ioctl+ring。排障时需按实际引擎分列证据包，避免用另一引擎的安装手册解释本引擎的日志。
Q&A
Falco 0.44.1 中 libscap 的主要职责是什么？
libscap 是 Falco libraries 中负责与内核驱动通信、打开/关闭捕获会话、读取 ring 缓冲、协商 API/Schema 版本，并处理 scap 文件读写和部分 OS 状态收集的组件。它是从 syscall 侧收集数据并与内核交互的统一捕获门面。
Falco 0.44 与 0.43 在驱动兼容性上有什么变化？
Falco 0.44.0 对驱动 API 和 schema 进行了 major bump，驱动版本从 9.1.0+driver 升至 10.2.0+driver。0.43 的驱动（kmod 和 modern_ebpf）与 0.44 用户态不兼容，反之亦然。同时删除了 legacy eBPF，进一步缩小了旧探针兼容的空间。
API Version 和 Schema Version 分别约束什么？
API Version 约束内核与用户态之间的通信机制，如 ioctl、ring、maps 等，随驱动和内核版本变化。Schema Version 约束驱动支持的事件类型集合和参数布局，当事件列表或字段变化时更新。两者都需要在启动时协商成功。
scap-open 工具的作用和边界是什么？
scap-open 是 libs 仓库提供的工具，用于从多种驱动 dump 原始事件，验证驱动是否产出 scap 编码事件，观察原始 type 和参数布局，对比引擎切换后原始流是否仍打开。但它不涉及规则条件求值、优先级、异常，也不包含 libsinsp 富化、进程树字段、输出 sink 等。它只能证明驱动和 libscap 工作正常，不能证明规则应该告警。
当 Falco 没有原始事件时，排障的第一步应该是什么？
排障的第一步是检查协商是否成功，而不是直接修改规则。具体检查顺序为：确认 engine.kind 意图 → 确认实际 Driver 行 → 确认 API/Schema 与 10.2.0+driver 对齐 → 再检查 ring 几何和规则。如果协商失败，应优先处理驱动加载或版本匹配问题。
modern_ebpf 和 kmod 在接口层有哪些主要差异？
modern_ebpf 探针可由 libscap 直接注入，通信使用 maps 和 BPF ring buffer，缓冲几何支持 buf_size_preset 和 cpus_for_each_buffer，权限失败可能涉及 capability 或 BPF 加载。kmod 必须预先安装 .ko，通信使用 ioctl 和 ring，缓冲几何只有 buf_size_preset，权限失败可能涉及模块签名、设备节点或特权安装。两者都检查 API/Schema。
