为什么用户空间版本的eBPF很有趣?

我已经看到ebpf 的用户空间版本(运行时、汇编器、反汇编器)正在开发中(uBPF、rbpf)。

为什么用户空间版本的 eBPF 很有趣?
这些替代方案是否与 eBPF 程序类型(网络、可观察性和安全性)关注相同的目标?

回答

eBPF 的主要优点之一是它在内核中运行代码。可观察性、内核数据聚合、早期数据包处理:这一切都发生在内核空间。所以这个问题听起来很合理:为什么要创建 uBPF 或 rbpf?

我认为它们主要是作为原型创建的。uBPF 在 eBPF 历史上很早就被引入,并且可能是 eBPF 解释器和 x86_64 JIT 在用户空间中的概念验证实现。我编写了 rbpf,它强烈基于 uBPF,我的主要目标是更加熟悉两件事:eBPF 和 Rust。很少事后考虑:)。

我一直很好奇人们可以用它做什么。说实话,用户并不多。rbpf 的最大用户可能是来自 Solana 的人,他们使用在 eBPF 机器上运行的智能合约实现了一些区块链工具。我过去遇到的另一个用例是调试一些 eBPF 字节码,因为在用户空间解释器中很容易出现断点(相比之下,目前常规内核 eBPF 的运行时调试非常有限)。

uBPF 取得了更大的成功,并被用作其他项目的基础,例如 DPDK 作为过滤库或Oko,Open vSwitch 的扩展(两者都与高性能网络处理有关)。[编辑 2021 年 8 月]最近,它被选为 eBPF 运行时,用于为 Windows 实现 eBPF(参考:公告,我的分析)。

如您所见,拥有这些用户空间 eBPF 机器的兴趣完全取决于您用它做什么。它们可用于运行 eBPF 程序,它们本身没有特定的重点,但如果您有用例,它们可以提供帮助。在这方面,uBPF 和 rbpf 的特殊性之一是它们的许可证(Apache、MIT):它们不受 GPL 保护,这意味着您可以将它们重用于更多项目,包括专有项目。来自内核的代码不是这种情况。

对于那些用户空间 eBPF 机器来说,一个很大的限制也是它们在内核中发生的事情方面往往已经过时了,内核中的事情发展很快。他们没有可靠的验证程序,因此您无法断言程序的安全性或安全性。他们几乎不支持 eBPF 映射,如果根本不支持函数调用或 BTF,甚至不支持最新的 eBPF 指令。其中一些可以添加,但这需要一些工程工作和时间。[编辑 2021 年 8 月] uBPF 现在得到了很多活动,因为微软为其 eBPF 实现做出了贡献。他们还使用用户空间验证器PREVAIL。


以上是为什么用户空间版本的eBPF很有趣?的全部内容。
THE END
分享
二维码
< <上一篇
下一篇>>