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

51–60 of 72 posts

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

#51

Post by deivid »

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…

IMO eBPF is best viewed as a mechanism that allows you to load "arbitrary" code in specific kernel paths, while guaranteeing that the kernel won't hang or crash.

That's it. Though I said "arbitrary" because the program has to pass the verifier, which limits valid programs to ones where it can make the stability guarantees.

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

#52

Post by convolvatron »

pjmlp wrote: post #6
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?

Yes, very bad, even worse when coming from supposedly security conscious programming language community.

I reflexively downvoted you. There has to be room for the evolution of operating systems and the maturation of new systems developers. this division of code into 'things we're allowed to understand' and 'the magic that we can't touch' has really been counterproductive for everyone.

but I realized that in the past decade or so all of my kernel experiments are being done in little baby kernels. virtualization and the sheer volume of open source makes this a perfectly good path. and frankly Linux isn't that lovely to work in and extend.

the current situation with kernel modules and symbol resolution is a crappy boundary that really gets in your way as a developer, and from a security perspective is really just crime scene tape.

so we should really try to clean up and harden production systems, and understand that we will need the playground to inform that activity. right now we have neither, and this clearly belongs in the playground.

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

#53

Post by nickpsecurity »

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.

I considering it now. Aside from correctness verification, the main reason we'd use a limited language for packet inspection is in case the policy is malicious. How often is that the case?

For most people, they trust most or all of the code running on their machine. They certainly trust their firewall policy to not be malware. If you already trust it, using a better, safe language might be helpful. In many cases, eBPF will be fine.

This isn't the first time this has been done. SPIN was an operating system in Modula-3 that allowed type-safe linking of code into the kernel, balancing safety and performance.

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

#54

Post by nickpsecurity »

johnisgood wrote: post #15
testdelacc1 wrote: post #13

Earlier quoted context omitted.

It’s a common HN trope to generalise a “community” based on a handful of people or even just one person. “See this is why I dislike the xyz community”, says a person justifying their confirmation bias. Perhaps the world is too complex without breaking it down into in-groups and out-groups, with any out-groups supposedly being completely homogenous. Pretty intellectually lazy but fairly common on HN, to the point wher…

I mean, I was going to reply "take a wild guess" to him, but your message is correct, too. (I may come across as an Ada zealot myself.)

Quick, random question. I heard way back that SPARK was getting safe pointers in response to Rust's borrow checker.

Has full Ada solved their unsafe de-allocation problem in a way that's comparable to the borrow checker's guarantees?

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

#55

Post by westurner »

IshKebab wrote: post #35
aliceryhl wrote: post #26

Earlier quoted context omitted.

I asked about this when they presented the project at the Linux Plumbers conference. They replied that it's not really intended to be a security boundary, and that you should not let anyone malicious load these programs. Given this thread model, I think their project is entirely reasonable. Safe Rust will prevent accidental mistakes even if you could technically circumvent it if you really try.

As I understand it eBPF has also given up on that due to Spectre. As a result you need root to use it on most distros anyway, and the kernel devs aren't going to expand its use (some systems are stuck on cBPF). So it's not like eBPF is secure and this isn't. They're both insecure in different ways.

So eBPF for a WAF isn't worth it?

re: eBPF and WAFs: https://news.ycombinator.com/item?id=45951011

From https://news.ycombinator.com/context?id=43564972 :

> Should a microkernel implement eBPF and WASM, or, for the same reasons that justify a microkernel should eBPF and most other things be confined or relegated or segregated in userspace; in terms of microkernel goals like separation of concerns and least privilege and then performance?

"Isolated Execution Environment for eBPF" (2025-04) https://news.ycombinator.com/item?id=43697214

"ePass: Verifier-Cooperative Runtime Enforcement for eBPF" (2025-12) https://ebpf.foundation/epass-verifier-cooperative-runtime-e... .. https://news.ycombinator.com/item?id=46412121

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

#56

Post by tptacek »

aliceryhl wrote: post #26
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.

I asked about this when they presented the project at the Linux Plumbers conference. They replied that it's not really intended to be a security boundary, and that you should not let anyone malicious load these programs. Given this thread model, I think their project is entirely reasonable. Safe Rust will prevent accidental mistakes even if you could technically circumvent it if you really try.

eBPF's limitations are as much about reliability as security. The bounded loop restriction, for instance, prevents eBPF programs from locking up your machine.

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

#57

Post by convolvatron »

twoodfin wrote: post #50
mirashii wrote: post #48

Earlier quoted context omitted.

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

its not a very well designed or stable api. its certainly not comprehensive.

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

#58

Post by vlovich123 »

mirashii wrote: post #46
vlovich123 wrote: post #42

Earlier quoted context omitted.

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.

eBPF still guarantees that a loaded program won’t crash or hang the kernel. Rex does let you hang the kernel.

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

#59

Post by dietr1ch »

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.

Can't my eBPF sched starve my monitoring processes, or my eBPF firewall rules prevent me from getting security updates?

If Eve gets to load bad eBPFs programs in your computer then I doubt counter-measures in how they run can save you.

Post reply on HN