问题描述
我看到正在开发 用户空间版本的 ebpf（运行时、汇编器、反汇编器）（uBPF、rbpf）。
为什么用户空间版本的 eBPF 很有趣？
这些替代方案是否与 eBPF 程序类型（网络、可观察性和安全性）关注相同的目标？
解决方法
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 取得了更大的成功，并作为 a filtering library 或 Oko,an extension to Open vSwitch（均与高性能网络处理相关）等其他项目的基础用作 DPDK。
如您所见，拥有这些用户空间 eBPF 机器的兴趣完全取决于您用它做什么。它们可用于运行 eBPF 程序，它们本身没有特定的重点，但如果您有用例，它们可以提供帮助。在这方面，uBPF 和 rbpf 的特殊性之一是它们的许可证（Apache、MIT）：它们不受 GPL 保护，这意味着您可以将它们重用于更多项目，包括专有项目。内核中的代码不是这种情况。
这些用户空间 eBPF 机器的一大限制还在于，它们在内核中发生的事情方面往往已经过时了，而内核中的事情发展很快。他们没有可靠的验证程序，因此您无法断言程序的安全性或安全性。他们几乎不支持 eBPF 映射，如果根本不支持函数调用或 BTF，甚至不支持最新的 eBPF 指令。其中一些可以添加，但这需要一些工程工作和时间。