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.
You could still imagine terminating these programs after some bounded time or cycle count. It isn't as good as static verification, but it's certainly more flexible.
If you're doing this kind of "optimistic" reliability story, where developers who stay on the happy path are unlikely to cause any real problems, I don't get what the value of something like this is over just doing a normal Rust LKM that isn't locked into a specific set of helpers.
You can extend the kernel functionality without having to develop a whole kernel module? Just because your module has no memory errors does not mean that it is working as intended.
Further, if you want to hook into specific parts of the kernel, you might well end up writing far more boilerplate instead of just intercepting the one call you're actually interested in and adding some metadata or doing some access control.
I personally am all for a kernel that can do more things for more people with less bespoke kernel modules or patches.
I guess my point is that the delta between a "whole kernel module" and a "Rex extension" is pretty small.
if nothing else, rex makes a good central place to evolve a set of helper code for doing ebpf-like stuff in a rust kernel module. wouldn't be too surprised if it eventually becomes closer to an embedded dsl.
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
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.
Evil eBPF programs can hide their presence from the bpf syscall as well.
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.
In this comment someone tries to justify its design, citing a lwn article: https://github.com/rex-rs/rex/issues/2#issuecomment-26965339...
I think this is a fair take:
> We currently do not support unprivileged use case (same as BPF). Basically, Rex extensions are expected to be loaded by privileged context only.
As I understand it, in privileged context would be one where one is also be able to load new kernel modules, that also don't have any limitations, although I suppose the system could be configured otherwise as well for some reasons.
So this is like a more convenient way to inject kernel code at runtime than kernel modules or eBPF modules are, with some associated downsides (such as being less safe than eBPF; the question about non-termination seems apt at the end of the thread). It doesn't seem like they are targeting to actually put this into mainstream kernel, and I doubt it could really happen anyway..
Yeah I agree with this assessment. It is not an eBPF replacement for many reasons. But could be a slightly safer alternative to kernel modules.
That's one aspect of the design. Again, complexity requirements are there for a reason. No explanation seen for why this eschews them.
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.
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)
> 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.
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.
A stable kernel API?
its not a very well designed or stable api. its certainly not comprehensive.
> 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.
The things you're missing:
1. This requires root.
2. eBPF also requires root usually. As I understand it it was originally meant to be secure enough to allow unprivileged use but Spectre ruined that and now they've given up on that.
How would Spectre, a timing attack that does not require root, affect whether eBPF is safe to run as root?
It doesn't. Spectre means unprivileged use of eBPF is insecure.
Yes, very bad, even worse when coming from supposedly security conscious programming language community.
They're not in the core language group... Do these people have influence in the stdlib, compiler, prominent libraries? Kernel community?
Why judge the whole Rust community for the choices made by one minor subgroup?
This has been covered ad nauseam, but since rust advocacy has waded into enough discussions about code in other languages to lecture people on performance and safety, it has naturally pushed some to find a bit of satisfaction in commenting on shortcomings in rust projects.
And this is very much also something which is helped along by the community’s defining voices.
Because the actions of everyone count to the wide perception of a community from the outside.
Rust Striking Force meme exists for a reason, their actions are also not supported by the core team.
>Rust Striking Force meme exists for a reason, their actions are also not supported by the core team.
Many of the core team and by large its community witness RESF in action for long before sending in a few words isn't exactly not supported in my book.
But then again I understand every PL needs a lot of push and marketing. It just went way too far in one direction.
Do they interact at all with the main rust community?
It seems a little disingenuous to describe "community" as including people who haven't even attempted to interact with anyone in the community other than forking their code.
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 where it’s not even worth calling out.
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?
You may be correct but pjmlp is not one of those and if you had been here long enough you would have known that. You're the one creating an in-group here and putting yourself on the 'good' side. Perhaps that is too complex for you but I think it is intellectually lazy not to get who you're referring to before making comments such as these. Note that your strawman "See this is why I dislike the xyz community" wasn't part of this thread at all.
A community is made by all of its participants.
One could also say some in the C or C++ communities actually care about security, thus no need for Rust or alike, yet no one is paying attention to those small groups in the corner.
A village is judged by its population actions, and even the black sheeps count to its overall image from outsiders.
Indeed. If there is one person here that keeps their footing in language debates it is you (and I'm always blown away with how many details you have at instant recall that I never realized were there). So thank you for the lessons over the years, it has helped me evaluate my choices better.
As for that sentence: I think Rust has its place, I do not agree at all with their 'rewrite' mantra because there are a ton of risks associated with rewrites that have nothing to do in what language the code is written in, just that it is a rewrite.
I think the Rust folks should go all-in on Redox and fix their tool optimization issues. And do one thing and do that well rather than to be the next Swiss army knife of programming. And I also think that the C and C++ folks can do a lot better still. Filip is doing something interesting I think and if there a practical solution to the C heritage I think it lies more in his direction than in rewriting billions of lines of battle tested code. Performance isn't nearly as important as it used to be. Another thing that I think would be beneficial would be to take as many device drivers out of the linux kernel as possible and run them as userspace processes.
Anyway, belated Merry Christmas to you and a pre-emptive happy 2026!
Same, all the best for 2026.
pjmlp is definitely one of those people, are you joking.
Bring out the pitchforks! Cancel him!!
ffs
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 me of being intellectually lazy for not giving high karma accounts the respect they deserve. Come off it. I’m going to judge comments by their content, not by the karma of the author. You shaming me is not going to make me change that.
What’s crazy is that judging people by their karma instead of their words is actually lazy. Isn’t this obvious? Do I need to get another 20k karma before you’ll understand that?
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. There is process, general hygiene and a lot of hard learned lessons about how you keep systems secure regardless of what language a particular piece of code is written in.
Given the amount of Rust evangelization on HN (which is one of the reasons this link got posted in the first place) and the fact that they can't let any opportunity go by to shit on other languages and those that use them for reasons that are unclear to me (and this goes quite far, up to and including questioning the sanity of anybody writing in a systems language other than Rust) you can expect that that higher standard is applied to the Rust advocates in the same way.
Action begets reaction.
Your response is telling: you make a personal attack on a member of HN and then hide behind pointing out the flaws in 'the community' when in fact it is you that is poisoning the community with these kind of comments.
I've made it a rule since a couple of weeks that I'm tossing accounts like that onto my blacklist because really, life's too short. If you don't see value in HN discussing languages and their communities (and I have to give the Rust community some credit here, as the language matures they've become more realistic about their abilities and there is less zealotry, especially Steve Klabik deserves a mention) then it may be that you are in the wrong place. For me your account will cease to exist after this comment.
I didn’t make a personal attack on anyone, although you did to me.
Me calling out a sock puppet account (0 karma, created minutes before) is not the same as you saying that high karma accounts need to have their opinions respected simply because they are high karma. Coincidentally, I notice your account is very high karma.
You’re acting extraordinarily offended, like I’ve committed some major transgression here. I haven’t. I’ve re-read my comments and they’re frankly milquetoast.
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.
"Bad thing" is an understatement.
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.
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.
Sorry dude, I don't want you guys vibecoding my kernel modules while spouting cargocult platitudes that "it can't have bugs, it's written in Rust".
We need a way to run HolyC in the kernel
You can run HolyC in the kernel. Just not the Linux kernel.
For the sake of safety, can't we simply have a back-end that emits eBPF?
We do; most people don't just write eBPF by hand.
https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...
REX is a BBS language back from the 90s ::))