Hacker News Reader

Comment by vlovich123 | Hacker News Reader

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.

View on HN

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

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.

Sure! Can't disagree with that.

In this comment someone tries to justify its design, citing a lwn article: https://github.com/rex-rs/rex/issues/2#issuecomment-26965339...

That's one aspect of the design. Again, complexity requirements are there for a reason. No explanation seen for why this eschews them.

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.

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.

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.

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.

Interesting. Any good read you'd recommend on the topic/attack? Thanks.

Look up "eBPF rootkits"

This is a good article about one found in the wild: https://www.synacktiv.com/en/publications/linkpro-ebpf-rootk...

Reply on news.ycombinator.com