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.
> 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..
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.
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.
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.
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.
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 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.
That's one aspect of the design. Again, complexity requirements are there for a reason. No explanation seen for why this eschews them.
> 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?
Yes, very bad, even worse when coming from supposedly security conscious programming language community.
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?
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.
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.
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.
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.
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.)
We need a way to run HolyC in the kernel
You can run HolyC in the kernel. Just not the Linux kernel.
These people just won't give up lol... Rust in the kernel is a terrible idea all around.