I know I may be a curmudgeonly old fart, but to echo clktmr's comment, in this case, it seems like a glorified strace(). It also seems like a lot of hype for something that seems to have potential to have lots of unintended consequences.
This can be packet-processing code to modify the way packets are routed, filtered, altered, or it can be used to instrument kernel codepath to monitor or debug issues.
The latter is what can be compared to strace(), but with strace() you only see what is happening at the userspace/kernel boundary. With eBPF you can actually look at what is going on in the kernel itself, which is really powerful.
The downside is that eBPF can be a pain to use with all those obscure tools tightly dependents upon your kernel release and options... But things are improving quickly and if you want to give it a try, I would recommend starting with bpftrace: https://bpftrace.org/
Are there ways that eBPF could be abused and if so what mitigations, limitations and logging can one implement so that eBPF can remain enabled in a hardened and sensitive environment?
[1] - https://utcc.utoronto.ca/~cks/space/blog/linux/DisablingUser...
https://www.brendangregg.com/blog/2019-01-01/learn-ebpf-trac...
https://www.usenix.org/conference/nsdi21/presentation/ghigof...
Another example is controlling the scheduler with ebpf.
The strace-like functionality is supposedly more efficient and is more convenient.
78436 cat PFLT 0x6c71f99cda8 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS 78436 cat PFLT 0x3c6efd36c280 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS 78436 cat PFLT 0x3c6efd36e158 0x2<VM_PROT_WRITE> 78436 cat PRET KERN_SUCCESS ...
Obviously not nearly as flexible as ebpf though. For instance it'll log all page faults happening in the context of the process, and so includes page faults that happen in the kernel due to copyin()/copyout() etc. Sometimes it's helpful and other times confusing.
