Rex

As a lover of Rust, ooo boy does this sound like a bad idea. The Rust compiler is not guaranteed to always output safe code against malicious inputs given that there’s numerous known soundness bugs that allow exploiting this. Unless I’m missing something this is a security nightmare of an idea.

Also there’s reasons why eBPF programs aren’t allowed to run arbitrarily long and this just ignores that problem too.

> This approach avoids the overly restricted verification requirements (e.g., program complexity constraints)

Maybe i'm missing something, but isn't that a bad thing?

We need a way to run HolyC in the kernel

These people just won't give up lol... Rust in the kernel is a terrible idea all around.

please don't (replace your typical eBPF filter with it, but do replace you custom kernel modules with it where viable ;) )

rust type system is not a security mechanism

it's a mechanism to avoid bugs which can become security issues not a way to enforce well behavior on a kernel boundary

as an example the current rust compiler has some bugs where it accepts unsound programs which are not seen as supper high priority as you most most likely won't run into them by accident. If rust where a verification system enforcing security at a kernel boundary this would be sever CVEs...

also eBPF verification checks more properties, e.g. that a program will deterministically terminate and can't take too long to do so, which is very important for the kind of thing eBPF is(1).

and eBPF programs are also not supposed to do anything overly complex or difficult to compute but instead should only do "simple" checks and accounting and potentially delegate some parts to user space helper program. So all the nice benefits rust has aren't really that useful.

In the end there is a huge gap between the kind of "perfect verification" you need for something like eBPF and "type checking to avoid nasty bugs". One defends against mistakes the other against malicious code.

To be fair if your use case doesn't fit into eBPF at all and you choice is rex-rs or a full kernel driver rex-rs is seems a far better choice then a full custom rust driver in a lot of way.

IMHO it would be grate if rust verification could become at some point so good that it can protect reliably against malicious code and have extensions for enforcing code with guaranteed termination/max execution budged. But rust isn't anywhere close to it, and it's also not a core goal rust development focused on.

(1): In case anyone is wondering how that works given that the halting problem is undecidable: The halting problem applies to any arbitrary program. But there are subsets of programs which can be proven to halt (or not halt). E.g. `return 0` is trivially proven to halt and `while True: pass` trivially to not halt (but `while(1){}` is UB in C++ and henceforth might be compiled to a program which halts, it's still an endless loop in C)

This is a pretty cool project and I think the comments here are being overly negative. Sure, removing the constraints that the eBPF verifier requires might encourage more complex and less performant code - but this is just another tool in the toolbox. For truly production systems, I can see the battle-tested eBPF being the top choice over a dubious kernel extension. But for quick prototyping? Rex can probably take the cake here once the project matures a bit more.

For the sake of safety, can't we simply have a back-end that emits eBPF?

This is a really interesting alternative to eBPF! The Rust safety guarantees + kernel extensibility combo is compelling. A few questions:

1. How does the safety model compare to eBPF's verifier? eBPF has the advantage of being verified at load time with strict constraints. Does Rex rely purely on Rust's type system, or is there additional runtime verification?

2. What's the performance story? eBPF is JIT-compiled and heavily optimized. How does Rex-compiled Rust code compare in terms of overhead and latency?

3. Deployment/distribution - eBPF programs can be distributed as bytecode. With Rex, do you need to compile on-target or ship platform-specific binaries?

4. What about the ecosystem? eBPF has massive tooling support (bpftrace, bcc, etc.). Is there a migration path for existing eBPF programs?

5. Kernel panic protection - eBPF has strict safety rails. If Rust code panics or has an unsafe block with UB, what happens?

6. Are there features that Rex enables that are impossible/difficult with eBPF? Complex data structures, async, better ergonomics?

The expressiveness vs. safety tradeoff is fascinating here. Would love to see benchmarks comparing identical functionality in both.

REX is a BBS language back from the 90s ::))