| ▲ | vlovich123 8 hours ago |
| 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. |
|
| ▲ | aliceryhl 5 hours ago | parent | next [-] |
| 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 4 hours ago | parent [-] | | 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. |
|
|
| ▲ | pjmlp 8 hours ago | parent | prev | next [-] |
| Fully agree. If it has to be native code, it should live on user space, at very least. |
| |
| ▲ | vlovich123 4 hours ago | parent [-] | | 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. |
|
|
| ▲ | benatkin 8 hours ago | parent | prev [-] |
| In this comment someone tries to justify its design, citing a lwn article: https://github.com/rex-rs/rex/issues/2#issuecomment-26965339... |
| |
| ▲ | _flux 6 hours ago | parent | next [-] | | 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 6 hours ago | parent [-] | | 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. |
| |
| ▲ | NewJazz 7 hours ago | parent | prev [-] | | That's one aspect of the design. Again, complexity requirements are there for a reason. No explanation seen for why this eschews them. | | |
|
