Live data from Hacker News

Rex is a safe kernel extension framework that allows Rust in the place of eBPF

github.com

61–70 of 72 posts

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#61
post #56

Earlier quoted context omitted.

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.

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.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#62
post #61
post #56

Earlier quoted context omitted.

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.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#63

Earlier quoted context omitted.

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 wher…

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 p…

pjmlp is definitely one of those people, are you joking.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#64
post #62
post #61

Earlier quoted context omitted.

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.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#65
post #64
post #62

Earlier quoted context omitted.

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 contr…

I guess my point is that the delta between a "whole kernel module" and a "Rex extension" is pretty small.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#66

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.

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.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#67
post #65
post #64

Earlier quoted context omitted.

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 contr…

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.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#68
post #63

Earlier quoted context omitted.

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 p…

pjmlp is definitely one of those people, are you joking.

Bring out the pitchforks! Cancel him!!

ffs

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#69
post #66

Earlier quoted context omitted.

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.

Re: Rex is a safe kernel extension framework that allows Rust in the place of eBPF

#70
post #62
post #61

Earlier quoted context omitted.

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.

Sure! Can't disagree with that.
Post reply on HN