【Falco】双引擎对照：modern_ebpf 与 kmod 等级路径
内容提要
Falco 0.44.1 仅支持 modern_ebpf 与 kmod 双引擎，legacy eBPF 已删除。modern_ebpf 需 BTF 与 ringbuf，可最小权限运行；kmod 需完整特权，适合旧内核或禁 BPF 环境。auto 仅是运维选择器，非第三引擎。排障须按实际加载引擎分列证据，避免误判。
延伸解读
auto 不是第三引擎，而是运维选择器
很多读者会把 Helm 的 driver.kind=auto 误认为第三条可核对引擎，但 auto 只是先尝试 modern_ebpf、必要时回退到 kmod 的运维选择器。它优化的是异构节点上的安装成功率，而不是排障的可观测性。排障时若 chart 写着 auto，第一步仍是核对实际加载的是哪一条等级路径，再套用对照表，否则会在能力集、设备节点与 iterators 门上同时指错。
kmod 并非遗留，而是可达性路径
0.44 删除的是 legacy eBPF，不是 kmod。kmod 仍是官方 Kernel Events 对照表里的一等列，承担的是可达性：当 BPF 程序加载被策略或内核特性挡住时，仍可能用已签名、已预构建或 DKMS 现场构建的模块继续采集。代价是特权面与驱动成对升级税——用户态升到 0.44.1 时，模块必须落到 10.2.0+driver，否则下一轴协商直接失败。
least-privileged 只适用于 modern_ebpf
官方文档明确 kmod 需要完整特权，不能仅靠 Linux capabilities 跑 least-privileged。把 modern_ebpf 的 capability 列表套到 kmod 上，属于轴 1 证据包指错引擎，不是「差一点就能最小权限」。Helm 的 modernEbpf.leastPrivileged 只对 modern_ebpf 有意义；把它抄到 kmod DaemonSet 上不会 magically 变成同等安全边界。
Q&A
Falco 0.44.1 支持哪两种驱动引擎？
Falco 0.44.1 支持 modern_ebpf 和 kmod 两种驱动引擎，legacy eBPF 已被删除。
modern_ebpf 引擎需要哪些内核特性？
modern_ebpf 引擎需要内核支持 BPF ring buffer 和 BTF，并且需要具备相关特性（如 tracing program 可用）。
kmod 引擎相比 modern_ebpf 有哪些不同？
kmod 引擎需要单独安装内核模块，需要完整特权，适用于旧内核或禁止 BPF 的环境；而 modern_ebpf 嵌入用户态二进制，可最小权限运行。
Falco 0.44.0 删除了哪些功能？
Falco 0.44.0 删除了 legacy eBPF 引擎、gVisor engine 和 gRPC output/server。
driver.kind=auto 在 Falco 中是什么含义？
driver.kind=auto 是运维选择器，不是第三引擎。它先尝试 modern_ebpf，必要时回退到 kmod，用于异构节点简化部署。
modern_ebpf 引擎的最小能力集包括哪些？
modern_ebpf 的最小能力集包括 CAP_SYS_RESOURCE、CAP_SYS_PTRACE、CAP_SYS_BPF 和 CAP_SYS_PERFMON，但某些环境可能仍需 CAP_SYS_ADMIN。
kmod 引擎是否支持 least-privileged 模式？
不支持。kmod 需要完整特权，不能仅靠 Linux capabilities 实现最小权限。
在排障时，如何根据实际加载的引擎分列证据？
排障时需先确认实际加载的是 modern_ebpf 还是 kmod，然后分别检查对应的能力集、设备节点、内核特性等，避免混用证据导致误判。
