3 ms·

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

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 10mo ago
In this comment someone tries to justify its design, citing a lwn article: https://github.com/rex-rs/rex/issues/2#issuecomment-2696533992 https://github.com/rex-rs/rex/issues/2#issuecomment-26965339...
- NewJazz 10mo ago
  That's one aspect of the design. Again, complexity requirements are there for a reason. No explanation seen for why this eschews them.
  - deleted 10mo ago
    [deleted]
- _flux 10mo ago
  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 10mo ago
    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 10mo ago
Fully agree. If it has to be native code, it should live on user space, at very least.
- vlovich123 10mo ago
  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 10mo ago
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 10mo ago
  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 10mo ago
    So eBPF for a WAF isn't worth it? re: eBPF and WAFs: https://news.ycombinator.com/item?id=45951011 https://news.ycombinator.com/item?id=45951011 From https://news.ycombinator.com/context?id=43564972 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 https://news.ycombinator.com/item?id=43697214 "ePass: Verifier-Cooperative Runtime Enforcement for eBPF" (2025-12) https://ebpf.foundation/epass-verifier-cooperative-runtime-enforcement-for-ebpf/ https://ebpf.foundation/epass-verifier-cooperative-runtime-e... .. https://news.ycombinator.com/item?id=46412121 https://news.ycombinator.com/item?id=46412121
- tptacek 10mo ago
  eBPF's limitations are as much about reliability as security. The bounded loop restriction, for instance, prevents eBPF programs from locking up your machine.
  - 10mo ago
nickpsecurity 10mo ago
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 10mo ago
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 10mo ago
  Evil eBPF programs can hide their presence from the bpf syscall as well.
  - ignoramous 10mo ago
    Interesting. Any good read you'd recommend on the topic/attack? Thanks.
    - ronsor 10mo ago
      Look up "eBPF rootkits" This is a good article about one found in the wild: https://www.synacktiv.com/en/publications/linkpro-ebpf-rootkit-analysis https://www.synacktiv.com/en/publications/linkpro-ebpf-rootk...

benatkin 10mo ago

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

NewJazz 10mo ago
That's one aspect of the design. Again, complexity requirements are there for a reason. No explanation seen for why this eschews them.
- deleted 10mo ago
  [deleted]
_flux 10mo ago
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 10mo ago
  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 10mo ago

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

vlovich123 10mo ago
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 10mo ago

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 10mo ago
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 10mo ago
  So eBPF for a WAF isn't worth it? re: eBPF and WAFs: https://news.ycombinator.com/item?id=45951011 https://news.ycombinator.com/item?id=45951011 From https://news.ycombinator.com/context?id=43564972 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 https://news.ycombinator.com/item?id=43697214 "ePass: Verifier-Cooperative Runtime Enforcement for eBPF" (2025-12) https://ebpf.foundation/epass-verifier-cooperative-runtime-enforcement-for-ebpf/ https://ebpf.foundation/epass-verifier-cooperative-runtime-e... .. https://news.ycombinator.com/item?id=46412121 https://news.ycombinator.com/item?id=46412121
tptacek 10mo ago
eBPF's limitations are as much about reliability as security. The bounded loop restriction, for instance, prevents eBPF programs from locking up your machine.
- 10mo ago

nickpsecurity 10mo ago

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 10mo ago

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 10mo ago
Evil eBPF programs can hide their presence from the bpf syscall as well.
- ignoramous 10mo ago
  Interesting. Any good read you'd recommend on the topic/attack? Thanks.
  - ronsor 10mo ago
    Look up "eBPF rootkits" This is a good article about one found in the wild: https://www.synacktiv.com/en/publications/linkpro-ebpf-rootkit-analysis https://www.synacktiv.com/en/publications/linkpro-ebpf-rootk...