Add eBPF kill example to readme

[niclashedam]

I made this example as part of my PhD. I think it's relevant for this repo.

[qmonnet]

Hi, thanks a lot for the link! Nice sample, although I have a couple of issues with it.

It is quite short, and does not demonstrate a lot of eBPF features and possibilities. killsnoop already permits to inspect calls to kill. This, by itself, is not blocking, and a short but nicely documented example to get started with eBPF would be interesting (although for a program of that size, would that make sense to have it as a blog post?).

Also, your program is not entirely correct. A few things I noticed, on a quick look:

• The loader program prints processes that were “forcefully killed”, but is that true? Won't you catch and log all calls to kill, including for example those passing SIGCONT?
• // All eBPF programs must be GPL licensed Not true. This depends on program types, eBPF helpers used and a couple of other features maybe. You need to be GPL-compatible in your case for using the tracepoint, but even then, you could have a dual license for example. Many networking programs do not have to be GPL-compatible at all.
• // We can call glibc functions in eBPF Probably true for some functions, such as labs() you use. But I'd be cautious here, I doubt that you could just call any function from the glibc - especially if some have loops.
• Why using the absolute value, by the way? Reading the syscall man page, it looks like calling kill() on a negative value has a specific meaning, wouldn't it be false to just take the positive value and to report it?

Worse, you build your program inside the kernel infrastructure. This means downloading all the kernel sources, simply to load a small program. You could have it self-contained. Plus it uses bpf_load.h from the kernel, which has been discouraged for a long time, and was even removed in the current development branch - meaning that in the future, your program will be impossible to build at all. My recommendation would be instead to switch to libbpf. This would also bring your more recent features, like the ability to use BTF to be able to dump (with bpftool, for example) your program code or map structure from the kernel. An example with those would be much more interesting, and I would be open to linking it.

[niclashedam]

Thank you very very much for the input. I wasn't aware that building eBPF programs with kernel infrastructure was disallowed. I will also extend the comments to be more specific. I'll get to these things very soon.

I agree that the program is very small, but that is one of the design choices. I've seen a lot of examples that were huge and impossible to understand as an outsider and I've seen projects containing a Makefile and a .c file. When I started learning eBPF I missed a plug & play example like this, where I could basically just clone it and tinker with it. I hope you'll still consider it for your repository, if I fix the other things.

[qmonnet]

Cool! Re-reading my comment, I hope it wasn't too demotivating. Your sample looks great! I'm realising that relying on the bpf_loader has been discouraged mostly on the development mailing list, but that it has not been advertised otherwise and it's far from obvious for people who don't read the ML. So you couldn't be blamed for that, apologies if I gave the wrong impression :).

As I said, the small size is not blocking in my opinion. And your argumentation makes sense to me. If you can rework it so it is self-contained, personally I'm OK to link it.

If you need some examples for self-contained eBPF programs and loaders, I know for sure that Netronome samples listed in the repo compile outside of the kernel. Others may do it also, I don't remember. Let me know if you are facing major issues :).

[niclashedam]

Your comment was perfect!

You point out some issues that I didn't think of and wasn't aware of and I'm very happy about that. My first impression was actually happiness, since you took time to read my code and provide me with valuable feedback, instead of just blindly accepting the PR. This is what I love about repos like these.

I'l definitely get it up to speed. If I can do anything to help with this repo, let me know!

[niclashedam]

Hi again. I restructured the whole build system to look like Netronomes. Everything compiles, verfies and runs, but something is clearly off. Libelf skips multiple unrecognized sections, and the eBPF program is never invoked.

nhed@nhed-1:~/Development/ebpf-kill-example$ make load
sudo LD_LIBRARY_PATH=./libbpf/src:D_LIBRARY_PATH src/ebpf-kill-example
libbpf: elf: skipping unrecognized data section(16) .eh_frame
libbpf: elf: skipping relo section(17) .rel.eh_frame for section(16) .eh_frame
eBPF will listen to force kills for the next 30 seconds!

Do you have any idea what could have triggered this behaviour? Code: https://github.com/niclashedam/ebpf-kill-example/pull/1/files

[qmonnet]

Yes. So the warning is harmless, I think, and can be safely ignored. I don't remember what causes it exactly, but I don't think this is a concern.

Your program loads successfully, and it is present in the kernel as long as your user process runs. However, it never get attached to the tracepoint, so it is never run. Libbpf does not do load + attach in a single step, so you would have to attach it explicitly. I don't remember exactly what function to use in your case (I'm more familiar with networking than tracing), but I see functions like bpf_program__attach() in kernel samples using libbpf. You might need an intermediary step to get a struct bpf_program * from your struct bpf_object * (with bpf_object__find_program_by_title() or bpf_object__find_program_by_name() maybe).

[niclashedam]

Hi @qmonnet ! Now the example is built using libbpf and all comments have been rewritten to be more semantically correct. Is there anything else you want me to look at before accepting this?

Thank you in advance.

[qmonnet]

Looks great, thanks for your work! I'll merge it. It would be nice if we could have BTF support for the map, I created a dedicated PR in your repo.

[niclashedam]

Thanks; I've accepted the PR on the repo 🎉

[niclashedam]

By the way; You mentioend a BPF mailing-list. Is this something I can subscribe to somewhere?

[qmonnet]

Certainly. There is the bpf mailing list: http://vger.kernel.org/vger-lists.html#bpf, it is used for development (kernel, libbpf, bpftool, sometimes other related components). I should warn you that there is a high volume on that list, you probably want to glimpse at the archives before subscribing.

There is also xdp-newbies which is much less active, where people ask questions from time to time: http://vger.kernel.org/vger-lists.html#xdp-newbies.

What kind of updates are you after? Have you seen the updates we publish on https://ebpf.io/blog?

[niclashedam]

I created the original ebpf-kill-example from resources I thought was up-to-date. I would like to have some way of knowing when the status-quo changes (fx. going from compiling in-kernel to using libbpf).