![eBPF 与经过验证的 Linux 内核模块](https://linux22.com/image/224976/eBPF%20%E4%B8%8E%E7%BB%8F%E8%BF%87%E9%AA%8C%E8%AF%81%E7%9A%84%20Linux%20%E5%86%85%E6%A0%B8%E6%A8%A1%E5%9D%97.png)
eBPF 在哪些方面优于用户端验证的内核模块?
我并不质疑验证代码的价值;两种方法都将得到完全静态验证。这两种方法都需要通常仅授予特权用户的功能。
然而,在用户空间中运行验证器可以让用户在验证器、安全级别和允许的假设之间有更多选择。验证器也可以独立于内核而更快速地开发。
在问这个问题之前我读过的东西:
我发现这个黑客新闻主题,这只是说一些有限的 eBPF 过滤器不需要特权,但我了解大多数 eBPF 应用程序仍然需要特权?
我发现这一页,它声称
内核模块有一个特定的入口点(init_module())和出口点(cleanup_module())。 eBPF 可以挂接到任何 kprobe/kretprobe/tracepoint,因此可用于跟踪
与之前的引用相反,根据 Linux 文档,kprobe/kretprobe/tracepoints 似乎可以从可加载内核模块中挂钩(也称为注册)kprobes/kretprobes和跟踪点。
这一页还声称 eBPF 不能被抢占,而内核模块可以。每当我搜索有关 Linux 内核抢占模块代码的任何内容时,他们总是谈论抢占用户空间而不是内核空间。我不知道“内核模块遵循常规内核代码抢占逻辑”意味着什么,但另一方面“eBPF 指令集执行不能被内核抢占”。