linux-kernel - 为什么用户空间版本的 eBPF 很有趣？

Question

我已经看到了 ebpf 的用户空间版本 (运行时、汇编器、反汇编器)正在开发中( uBPF 、 rbpf )。
为什么用户空间版本的 eBPF 很有趣？
这些替代方案是否与 eBPF 程序类型(网络、可观察性和安全性)关注相同的目标？

Answer 1

eBPF 的主要优点之一是它在内核中运行代码。可观察性、内核数据聚合、早期数据包处理:这一切都发生在内核空间。所以这个问题听起来很合理:为什么要创建 uBPF 或 rbpf？
我认为它们主要是作为原型(prototype)创建的。 uBPF 在 eBPF 的历史中很早就被引入，并且可能是用户空间中 eBPF 解释器和 x86_64 JIT 的概念验证实现。我编写了 rbpf，它强烈基于 uBPF，我的主要目标是更加熟悉两件事:eBPF 和 Rust。很少事后考虑:)。
我一直很好奇人们可以用它做什么。说实话，用户并不多。 rbpf 的最大用户可能是来自 Solana 的人，他们实现了一些 blockchain tool with smart contracts run in the eBPF machine .我过去遇到的另一个用例是调试一些 eBPF 字节码，因为在用户空间解释器中很容易出现断点(相比之下，目前常规内核 eBPF 的运行时调试非常有限)。
uBPF 取得了更大的成功，并被用作 DPDK 等其他项目的基础 a filtering library或 Oko, an extension to Open vSwitch (都关于高性能网络处理)。 [2021 年 8 月编辑] 最近，它被选为 the implementation of eBPF for Windows 的 eBPF 运行时(引用: announcement 、 my analysis )。
如您所见，拥有这些用户空间 eBPF 机器的兴趣完全取决于您用它做什么。它们可用于运行 eBPF 程序，它们本身没有特定的重点，但如果您有用例，它们可以提供帮助。在这方面，uBPF 和 rbpf 的特殊性之一是它们的许可证(Apache、MIT):它们不受 GPL 保护，这意味着您可以将它们重用于更多项目，包括专有项目。来自内核的代码不是这种情况。
那些用户空间 eBPF 机器的一大限制还在于，它们在内核中发生的事情方面往往已经过时了，而内核中的事情发展很快。他们没有可靠的验证程序，因此您无法断言程序的安全性或安全性。他们几乎不支持 eBPF 映射，如果根本不支持函数调用或 BTF，甚至不支持最新的 eBPF 指令。其中一些可以添加，但这需要一些工程工作和时间。 [2021 年 8 月编辑] uBPF 现在得到了很多事件，因为微软为其 eBPF 实现做出了贡献。他们还使用用户空间验证器，PREVAIL .