alt Hacker NewsAs 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.
Replies
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.
Fully agree.
If it has to be native code, it should live on user space, at very least.
In this comment someone tries to justify its design, citing a lwn article: https://github.com/rex-rs/rex/issues/2#issuecomment-26965339...
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.
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.