Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rex is a safe kernel extension framework that allows Rust in the place of eBPF

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#41

Post by [deleted] »

jacquesm wrote: post #31
testdelacc1 wrote: post #27

Earlier quoted context omitted.

That dude said “even worse when coming from supposedly security conscious programming language community”. The comment is dripping with contempt, pointing out that the “community” makes tall claims that are unfounded. And he said this based purely on one comment. This contempt clearly indicated a dislike, which I generalised to “I dislike xyz community”. To which you reply with “strawman”. Sure. You’re then accusing…

Here's you: https://news.ycombinator.com/item?id=46352728 So apparently it is fine for you to call out low karma accounts but I can't have you shit on a member in excellent standing here? The Rust community has - rightly, in my opinion - flagged a number of serious concerns about language safety. Outside of that Rust is just another programming language and languages are just one of the parts of the security picture.…

[deleted]

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#42

Post by vlovich123 »

calmingsolitude wrote: post #29

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 th…

It’s not about battle testing but that eBPF is has specific restrictions that a) won’t lock up your kernel b) won’t cause a security exploit by being loaded. Now Spectre throws a wrench in things, but the framing is weird; why compare it to eBPF vs just making a mechanism to load kernel modules written in Rust.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#43

Post by vlovich123 »

pjmlp wrote: post #5
vlovich123 wrote: post #2

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.

Fully agree. If it has to be native code, it should live on user space, at very least.

Or at the very least it should be framed as a way to load kernel modules written in Rust. I just don’t understand the framing that this is an alternative to eBPF programs.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#46

Post by mirashii »

vlovich123 wrote: post #42
calmingsolitude wrote: post #29

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 th…

It’s not about battle testing but that eBPF is has specific restrictions that a) won’t lock up your kernel b) won’t cause a security exploit by being loaded. Now Spectre throws a wrench in things, but the framing is weird; why compare it to eBPF vs just making a mechanism to load kernel modules written in Rust.

> why compare it to eBPF vs just making a mechanism to load kernel modules written in Rust.

Because it's not just a mechanism to load kernel modules in Rust, it's specifically a mechanism to load them in the same places that ebpf programs are loadable, using the existing kernel machinery for executing ebpf programs, and with some helpers to interface with existing epbf programs.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#48

Post by mirashii »

dathinab wrote: post #28

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 a…

> which is very important for the kind of thing eBPF is(1)

The question is, going into 2026, what kind of thing is eBPF? It seems like all hope of it being a security boundary has been thwarted by micro-architectural vulnerabilities to the extent that you can no longer load eBPF programs as non-root. So, is it a security boundary? That's an honest question that I've not been able to find an answer to in the kernel documentation or recent mailing list posts.

If it's not a security boundary, what is it? There's a few other nice properties enforced by the validator, like protos for a subset of kernel functions, which provides some load-time validation that you've built against a compatible kernel. That's something that's lost here, so we don't get the same compile once, run everywhere properties eBPF has. One might argue this is a big loss, but in the branch that eBPF is not a security subsystem, it's worth asking whether these are strictly necessary checks that need to be enforced, or whether they're niceties that bring a higher hope of stability and reduce the burden of code review that are perfectly fine to bypass given those caveats.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#49

Post by viraptor »

bawolff wrote: post #3

> 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?

Depends. If you want to implement a very fancy kernel level tracing tool for your local environment, why would it be a bad thing? Worst case you'll lock up your system and have to reboot.

But you wouldn't want to use that for the actual firewall for example, or with a production service. There's no general "bad". Just different contexts.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#50

Post by twoodfin »

mirashii wrote: post #48
dathinab wrote: post #28

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 a…

> which is very important for the kind of thing eBPF is(1) The question is, going into 2026, what kind of thing is eBPF? It seems like all hope of it being a security boundary has been thwarted by micro-architectural vulnerabilities to the extent that you can no longer load eBPF programs as non-root. So, is it a security boundary? That's an honest question that I've not been able to find an answer to in the kernel do…

A stable kernel API?
Post reply on HN