[HN Gopher] Rex is a safe kernel extension framework that allows...
___________________________________________________________________
Rex is a safe kernel extension framework that allows Rust in the
place of eBPF
Author : zdw
Score : 134 points
Date : 2025-12-23 02:58 UTC (5 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| vlovich123 wrote:
| 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.
| benatkin wrote:
| In this comment someone tries to justify its design, citing a
| lwn article: https://github.com/rex-
| rs/rex/issues/2#issuecomment-26965339...
| NewJazz wrote:
| That's one aspect of the design. Again, complexity
| requirements are there for a reason. No explanation seen for
| why this eschews them.
| _flux wrote:
| 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..
| NewJazz wrote:
| 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.
| pjmlp wrote:
| Fully agree.
|
| If it has to be native code, it should live on user space, at
| very least.
| vlovich123 wrote:
| 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.
| aliceryhl wrote:
| 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.
| IshKebab wrote:
| 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.
| westurner wrote:
| 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
| tptacek wrote:
| eBPF's limitations are as much about reliability as security.
| The bounded loop restriction, for instance, prevents eBPF
| programs from locking up your machine.
| loeg wrote:
| 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.
| tptacek wrote:
| 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.
| eptcyka wrote:
| 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.
| tptacek wrote:
| I guess my point is that the delta between a "whole
| kernel module" and a "Rex extension" is pretty small.
| zem wrote:
| 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.
| nickpsecurity wrote:
| 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.
| dietr1ch wrote:
| 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.
| ronsor wrote:
| Evil eBPF programs can hide their presence from the bpf
| syscall as well.
| ignoramous wrote:
| Interesting. Any good read you'd recommend on the
| topic/attack? Thanks.
| bawolff wrote:
| > 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?
| pjmlp wrote:
| Yes, very bad, even worse when coming from supposedly security
| conscious programming language community.
| NewJazz wrote:
| 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?
| testdelacc1 wrote:
| 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.
| johnisgood wrote:
| 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.)
| nickpsecurity wrote:
| 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?
| jacquesm wrote:
| 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.
| pjmlp wrote:
| 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.
| jacquesm wrote:
| 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!
| pjmlp wrote:
| Same, all the best for 2026.
| testdelacc1 wrote:
| 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?
| jacquesm wrote:
| 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.
| testdelacc1 wrote:
| 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.
| loeg wrote:
| pjmlp is _definitely_ one of those people, are you
| joking.
| jacquesm wrote:
| Bring out the pitchforks! Cancel him!!
|
| ffs
| pjmlp wrote:
| 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.
| ksec wrote:
| >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.
| monocasa wrote:
| 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.
| pseudony wrote:
| 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.
| convolvatron wrote:
| 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.
| otabdeveloper4 wrote:
| "Bad thing" is an understatement.
| IshKebab wrote:
| 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.
| p-e-w wrote:
| How would Spectre, a timing attack that does _not_ require
| root, affect whether eBPF is safe to run as root?
| IshKebab wrote:
| It doesn't. Spectre means _unprivileged_ use of eBPF is
| insecure.
| viraptor wrote:
| 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.
| dracarys18 wrote:
| We need a way to run HolyC in the kernel
| logicchains wrote:
| You can run HolyC in the kernel. Just not the Linux kernel.
| dathinab wrote:
| 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)
| mirashii wrote:
| > 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.
| twoodfin wrote:
| A stable kernel API?
| convolvatron wrote:
| its not a very well designed or stable api. its certainly
| not comprehensive.
| deivid wrote:
| 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.
| calmingsolitude wrote:
| 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.
| otabdeveloper4 wrote:
| 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".
| vlovich123 wrote:
| 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.
| mirashii wrote:
| > 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.
| vlovich123 wrote:
| eBPF still guarantees that a loaded program won't crash or
| hang the kernel. Rex does let you hang the kernel.
| amelius wrote:
| For the sake of safety, can't we simply have a back-end that
| emits eBPF?
| vitus wrote:
| We do; most people don't just write eBPF by hand.
|
| https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...
| larodi wrote:
| REX is a BBS language back from the 90s ::))
___________________________________________________________________
(page generated 2025-12-28 23:00 UTC)