dangisafascist

6 ms·

1. 1.▲
   Ask HN: What percentage of HN users are entrepreneurs?

   4 points by dangisafascist 9y ago|7 comments
2. 2.▲
   by dangisafascist 9y 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?
3. 3.▲
   by dangisafascist 9y ago

   The bpf() system call and SOCK_RAW both require root. Is there an example of using bpf that doesn't require root?
4. 4.▲
   by dangisafascist 9y 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 e
5. 5.▲
   by dangisafascist 9y ago

   If you write your kernel module in eBPF (by pre-compiling to native code) it can't crash either.
6. 6.▲
   by dangisafascist 9y 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
7. 7.▲
   by dangisafascist 9y ago

   I can but I don't see why that is necessary. It's plain to see that it's possible and performs better in production since it avoids the JIT step. https://github.com/tsgates/rust.ko
8. 8.▲
   by dangisafascist 9y 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 ben
9. 9.▲
   by dangisafascist 9y ago

   I'm confused why BPF exists in the first place. Can't we just compile kernel modules that hook into the tracing infrastructure? It seems like a webassembly for the kernel but local software has the benefits of knowing the platform