Recent submissions

Comment · 9 years ago
Sure but how common is that case? How common are multi-tenant Linux systems with untrusted users that give those specific permissions? Do you want untrusted users sniffing the packets of others?
Comment · 9 years ago
The bpf() system call and SOCK_RAW both require root. Is there an example of using bpf that doesn't require root?
Comment · 9 years ago
For experimentation and testing, a kernel module for each rule doesn't seem unworkable. Just hide all the details behind a nice tool.

For production, placing all rules in a single module seems best. If you could avoid the overhead of executing BPF in production, wouldn't you?

I agree with the privilege argument but I don't think normal users can filter packets or add tracing with the current situation either.

Comment · 9 years ago
If you write your kernel module in eBPF (by pre-compiling to native code) it can't crash either.
Comment · 9 years ago
I'm not arguing against eBPF the language. It's safety guarantees make sense to me.

I'm arguing against the in-kernel eBPF infrastructure: bpf system call, the JIT and the VM.

I think it makes more sense to just compile eBPF (or rust or whatever safe language you want) to a kernel module.

Comment · 9 years ago
Comment · 9 years ago
I'm not sure this argument makes sense. Avoiding accidentally crashing the kernel doesn't require a BPF layer.

For instance, you could just write your kernel module in a sufficiently safe language, like Rust, and have the same benefits. You could even pre-compile eBPF for the exact same level of safety. Still no need for the bpf() system call or the eBPF VM or JIT in the kernel.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton