One cool project that uses eBPF is Cilium. It allows restricting network traffic to / from containers in Kubernetes. Many of the problems it solves, in my opinion, are better solved via user-space solutions, e.g. service-to-service traffic is better controlled via signing / encryption, but overall Cilium is a pretty cool piece of technology.
Notes on BPF and eBPF
21–30 of 46 posts
Re: Notes on BPF and eBPF
#22BPF is indeed a pretty interesting technology. As the knowledge about it becomes more widespread, I anticipate that we will unlock some new capabilities both in terms of tracing. Brendan Gregg's book ( https://www.brendangregg.com/bpf-performance-tools-book.html ) serves as a good intro to this, although you probably only need to read a small chunk of it as a lot of it is reference-book-style material. The author's m…
>With the proper BPF tracing scripts, I think we can validate that programs indeed avoids page faults Sorry, I'm a little confused why this would be necessary? Like, sure, it's a nice to have on a CI as a basic sanity check but if you just invoke mlockall you'll end up with everything wired down and you're good to go regardless?
Yeah you're right on that one. I probably over-extended the use case here as I'm still just learning about this and thus tried to apply it to everywhere. I guess one thing you can maybe do is to use CI to validate that mlockall indeed has been called, haha. That said it's probably overkill as other tools can probably do this too.
While on that thought experiment, perhaps in general if you can use BPF/USDT to help trace/debug RT programs? I'm thinking of being able to verify/visualize timing for better tracing? Or maybe there are already tools that existing that I don't really know how to use (like ftrace + trace compass, maybe)
Re: Notes on BPF and eBPF
#23Earlier quoted context omitted.
Easier to get started maybe, but there's something to be said for the 'ease' of having to worry a lot less about crashing the kernel you're working on.
I've crashed multiple kernels with eBPF programs. I don't buy this argument at all.
Those would be considered kernel bugs though, and should be getting fixed when reported. While a crash in a kernel module is just a bug in the kernel module itself
Re: Notes on BPF and eBPF
#24Earlier quoted context omitted.
Easier to get started maybe, but there's something to be said for the 'ease' of having to worry a lot less about crashing the kernel you're working on.
I've crashed multiple kernels with eBPF programs. I don't buy this argument at all.
I said 'less' rather than 'at all' for a reason. I'm not really sure what to tell you if you disagree that it's a lot easier to accidentally crash your kernel with a from-scratch module than ebpf though. That's an experience pretty drastically at odds with mine.
Re: Notes on BPF and eBPF
#25>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
Yes, "can't" should be replace by "shouldn't". If there's a physical possibility, it's just a matter of time before someone finds a way, as was proved by the CPU cache bugs leaking information.
"shouldn't" is ambiguous as it might suggest the responsibility is with the the user of eBPF rather than internal to it.
Perhaps "is designed not to" but that's a mouthful.
I think we should accept "can't" and yet know the limitations of certainty.
Re: Notes on BPF and eBPF
#26I tried clicking on the link with these words: "The BSD Packet Filter: A New Architecture for User-level Packet Capture". The link appears to be an unsecure website that my internet browser preevented me from going on.
Re: Notes on BPF and eBPF
#27>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
I think they already don't. eBPF has become a favorite jumping point for exploit chains that can very quickly escalate some read/write gadget into full execution.
Re: Notes on BPF and eBPF
#28Earlier quoted context omitted.
Easier to get started maybe, but there's something to be said for the 'ease' of having to worry a lot less about crashing the kernel you're working on.
I've crashed multiple kernels with eBPF programs. I don't buy this argument at all.
I call bullshit! Ebpf programs cannot crash the kernel since they cannot be run if they contain bugs in the first place.
Re: Notes on BPF and eBPF
#29Earlier quoted context omitted.
I've crashed multiple kernels with eBPF programs. I don't buy this argument at all.
I call bullshit! Ebpf programs cannot crash the kernel since they cannot be run if they contain bugs in the first place.
That assumes that the virtual machine has no bugs
Re: Notes on BPF and eBPF
#30Earlier quoted context omitted.
The BPF capability should really only be given to root. I don't think it really gives any new attack surface. All I could see is it giving black-hats an easier interface to "kernel-level-fuckery".
It’s not an easier interface. It’s much easier to write kernel modules than to mess around with eBPF.
That seems wrong. The build environment for eBPF programs is simpler (you don't even need a working kernel tree), and, much more importantly, eBPF programs are constrained and can't crash the kernel, which is easy to do accidentally when writing an freestyle C LKM. You can learn enough to get stuff done with eBPF inside of a couple days; the same is absolutely not true of kernel modules.