【发布时间】：2021-04-30 10:47:23
【问题描述】：
我看到 用户空间版本的 ebpf（运行时、汇编器、反汇编器）正在开发中（uBPF、rbpf）。
为什么拥有 eBPF 的用户空间版本很有趣？
这些替代方案是否与 eBPF 程序类型（网络、可观察性和安全性）关注相同的目标？
【问题讨论】：
标签： linux-kernel bpf ebpf
【发布时间】：2021-04-30 10:47:23
【问题描述】：
eBPF 的主要优点之一是它在内核中运行代码。可观察性、内核内数据聚合、早期数据包处理：这一切都发生在内核空间中。所以这个问题听起来很合理：为什么要创建 uBPF 或 rbpf？
我认为它们主要是作为原型创建的。 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。
【讨论】：