Why is having an userspace version of eBPF interesting?

Question

I've seen that userspace version of ebpf (runtime, assembler, dissasembler) are being developped (uBPF, rbpf).

Why is having an userspace version of eBPF interesting ?
Do those alternatives focus on the same goal than the eBPF program types (network, observability and security) ?

Answer 1

Here are some examples why userspace BPF might be desired:

There are cases where applications want to allow future extensions without knowing in what directions it could be extended. Take into consideration how kernel or envoy proxy are extended beyond its wildest dream. In such cases you need some way of extending either through something like WASM or uBPF or plugin framework. The advantage of uBPF is that it can restrain what the input bytecode can do i.e., it would (ideally) never allow the input bytecode to crash the target application. These guarantees are not provided WASM or plugin frameworks.

Recently, I came across a telco provider who is working on 5G ORAN implementation for O-DU. O-DU, O-CU are E2 nodes who exports all sorts of stats/metrics for observability/monitoring of UEs. They couldn't possibly fathom all the metrics that could be exported on day one and thus needed an elegant extension mechanism. They are prototyping with ubpf primarly because of its light-weight, fast-path behaviour and the ability to restrain what gets deployed by doing some back checks using verifier.

Answer 2

One of the main advantages of eBPF is that it runs code in the kernel. Observability, in-kernel data aggregation, early packet processing: it all happens in kernel space. So the question sounds legit: Why were uBPF or rbpf created?

I think they were created mostly as prototypes. uBPF was introduced very early in eBPF history, and was probably a proof-of-concept implementation of an eBPF interpreter and x86_64 JIT in user space. I wrote rbpf, which is strongly based on uBPF, and the main objective for me was to get more familiar with two things: eBPF and Rust. Very little afterthought :).

I've always been curious to see what people could do with it. Truth to tell, there are not so many users. The biggest users for rbpf are probably the people from Solana, who implement some blockchain tool with smart contracts run in the eBPF machine. One other use case I've had in the past was to debug some eBPF bytecode, because it is easy to have breakpoints in an user space interpreter (by contrast, runtime debugging for regular kernel eBPF is quite limited at this time).

uBPF had more success and was used as a basis for other projects like DPDK as a filtering library or Oko, an extension to Open vSwitch (both about high-performance network processing). [Edit August 2021] More recently, it was chosen to serve as an eBPF runtime for the implementation of eBPF for Windows (references: announcement, my analysis).

As you can see, the interest of having these user space eBPF machines entirely depends on what you do with it. They're available to run eBPF programs, they don't have a specific focus by themselves, but they can help if you have a use case. In that regard, one of the particularities for uBPF and rbpf is their licenses (Apache, MIT): They are not under GPL, which means that you could reuse them with a larger number of projects, including proprietary ones. This is not the case with code from the kernel.

One big limitation for those user space eBPF machines is also that they tend to be quite out-of-date with regards to what happens in the kernel, where things evolve fast. They don't have a solid verifier, so you cannot assert security or safety of the programs. They hardly support eBPF maps if at all, they do not support function calls, or BTF, or even the latest eBPF instructions for that matter. Some of it could be added, but this would require some engineering efforts and time. [Edit August 2021] uBPF is getting a lot of activity now that Microsoft contributes to it for its eBPF implementation. They also use a user-space verifier, PREVAIL.