【Falco】libsinsp：状态富化与用户态进程树
内容提要
本文介绍Falco libsinsp状态富化机制：通过线程/FD表将原始事件转为规则可引用字段，依赖事件流与/proc或BPF iterators回填。富化字段可能因丢事件、回填失败而空洞，导致条件静默为假。用户态进程树非内核权威状态，与Tetragon exec_id不同。排障时需区分富化失败与规则未加载。
延伸解读
状态表是工作集，不是账本
libsinsp 的线程/FD 表是检测引擎为求值准备的工作集，而非系统全部事实的账本。事件丢失、回填失败或 plugin 元数据空都会在表中留下空洞，规则条件读到的是空洞，不是“威胁为零”。理解这一点，有助于避免将字段缺失误判为规则未加载或驱动故障。
富化字段空 ≠ 驱动没看见 syscall
规则字段如 fd.name 或网络元组是富化结果，依赖事件流与回填的连续性。字段空可能源于 FD 尚未入表、事件被 drop、回填未完成或 plugin 键缺失。排障时应优先检查事件完备性与回填路径，而非直接修改规则或重装 chart。
用户态进程树与内核权威状态的区别
Falco 的进程树是用户态工作集，依赖事件流与回填，不是内核 execve_map 的别名。drop 或回填失败会造成父子/FD 对不齐的局部视图，短命进程、高频 fork 等场景下字段可能缺失。这与 Tetragon 的 exec_id 不同，后者以内核 map 为权威，过滤位置也不同。
富化失败的表象与排查方向
测试机命中而集群不命中时，若条件含 container.* 或 K8s 键，优先怀疑 plugin 元数据空或容器运行时插座不可见；有原始事件但路径条件永不真时，优先怀疑 FD 表空洞或 drop；进程名条件偶发假时，考虑短命进程或表项回收。区分富化失败与规则未加载，是排障的关键。
Q&A
Falco libsinsp 的状态富化是什么？它如何将原始事件转换为规则可引用的字段？
libsinsp 通过维护线程/FD 表等机器状态，将原始事件富化为规则可引用的字段，如 fd.name、proc.*、网络元组等。它依赖事件流持续更新状态表，并在启动或丢事件后通过 /proc 或 BPF iterators 回填。
Falco 用户态进程树与 Tetragon 的 exec_id 有何不同？
Falco 的用户态进程树是 libsinsp 为检测维护的工作集，不是内核权威状态，依赖事件流和回填，可能因丢事件或回填失败而残缺。Tetragon 的 exec_id 由节点名、内核 ktime 和 PID 组成，权威状态在内核 execve_map，过滤可在 hook 内完成。
为什么 Falco 规则条件可能因富化字段为空而静默为假？
富化字段可能因事件丢失、回填失败或 plugin 元数据为空而出现空洞，导致规则条件读取到空值，从而静默不命中。例如，FD 表空洞或容器元数据缺失时，相关条件会为假。
Falco 0.44.0 在状态富化方面做了哪些性能优化？
Falco 0.44.0 重写了用户态 /proc 上的进程元数据与网络/FD 解析器，并引入 modern_ebpf 侧 BPF iterators 辅助初始状态和 drop 后愈合，降低了冷启动和 drop recovery 的 CPU/分配成本。
在 Falco 排障中，如何区分富化失败与规则未加载？
如果规则已加载但无告警，且条件涉及 container.* 或路径字段，优先怀疑 plugin 元数据空或 FD 表空洞；如果无任何 scap 事件，则先检查驱动/协商。falco -L 可见规则且字段非空仍无告警，则偏向规则条件问题。
Falco 用户态进程树有哪些局限性？
用户态进程树依赖事件完备性，drop 会导致父子/FD 对不齐；回填有成本与失败模式，如 /proc 竞态和 iterators 命名空间限制；不消除 TOCTOU 类窗口；短命进程、高频 fork 等会留下可观察的残缺。
