support attaching to tracepoints about ebpf

[mythi]

@lmb I'm currently using iovisor/gobpf and just last week I built a POC that gives me the same functionality using cilium/ebpf.

In my POC, I loaded an ELF built using clang (tried LoadCollectionSpecFromReader and LoadCollection) . cilium/ebpf supports ways to overcome that cgo issue mentioned above and here's what I needed to add on top:

	attr := unix.PerfEventAttr{
		Type:        unix.PERF_TYPE_TRACEPOINT,
		Config:      uint64(tid), // tracepoint id
		Sample_type: unix.PERF_SAMPLE_RAW,
		Sample:      1,
		Wakeup:      1,
	}
	pfd, err := unix.PerfEventOpen(&attr, -1, 0, -1, unix.PERF_FLAG_FD_CLOEXEC)
	if err != nil {
		return -1, errors.Wrap(err, "unable open perf events")
	}
	if _, _, errno := unix.Syscall(unix.SYS_IOCTL, uintptr(pfd), unix.PERF_EVENT_IOC_ENABLE, 0); errno != 0 {
		return -1, errors.New("unable to set up perf events")
	}
	if _, _, errno := unix.Syscall(unix.SYS_IOCTL, uintptr(pfd), unix.PERF_EVENT_IOC_SET_BPF, uintptr(fd)); errno != 0 {
		return -1, errors.New("unable to attach bpf program to perf events")

AFAICS, it's not much that needs to be added. I'm still going to check/learn how craft tracepoint programs without pre-compiling (it's not a hard requirement for me right now though)

[lmb]

Hi! We had a similar discussion on Slack a while ago. Here is the thread for posterity:

Grant Seltzer Feb 22nd at 1:04 AM
Hi everyone, I'm excited about this package but from reading documentation I don't get the impression that I can load a uprobe using it yet, is that correct?

Joe Stringer  1 month ago
Correct. At this stage this library is not intending to take over all BPF use case like tracing, it's more focused on networking use cases where the BPF programs are managed by long-running daemons.

Grant Seltzer  27 days ago
Would there be interest in that feature if I were to try to implement it? I think having static go binaries that can do eBPF tracing would be widely appreciated

Lorenz  27 days ago
Do you have a rough idea what features you want? Contributions are always welcome of course, the main questions for me are who will maintain that code, and how much additional API surface does it expose?

Lorenz  27 days ago
Especially allowing uprobes on old kernels will be difficult i think

pbnj  26 days ago
Grant, have you seen this project: https://github.com/iovisor/gobpf

Grant Seltzer  26 days ago
@pbnj Yes, I'm currently using that for a project i'm working on: https://github.com/grantseltzer/weaver

Grant Seltzer  26 days ago
I could be misunderstanding the function and purpose of this package, but the iovisor gobpf package requires dynamic linking/CGO. If there were a purely go alternative then I could make my program which instruments ebpf into a static binary, right?

Lorenz  24 days ago
yes, with the caveat that you need to ship your compiled ebpf somehow

Lorenz  24 days ago
since you're using uprobes, do you rely on CO-RE / BTF at all?

Lorenz  24 days ago
you can try the following, and see how it goes: turn the gobpf C into something you can compile with vanilla clang, and try to load it with the library. if you put the function in a uprobe section the library should recognize it: https://github.com/cilium/ebpf/blob/master/elf_reader.go#L542 (edited) 
elf_reader.go:542

        "uretprobe/":      Kprobe,

Lorenz  24 days ago
at that point you can take a look at adding a function that attaches the ebpf to the user function, not sure how that works

From my POV it boils down to how much additional code we need for tracepoint support. For example, I suspect that supporting libbpf-style Compile-Once Rune-Everywhere is a good chunk of code. Since we don't have a use case for it at the moment I'd rather not have to maintain that. If you can do without we can probably accomodate your use case.

[lmb]

Hi Mikko, sorry for the late reply. There is currently a proposal to add a "BPF link" to the kernel: https://lore.kernel.org/bpf/?q=bpf_link The idea is that this will unify attaching BPF to things, which would be great for this library of course. I'd like to wait and see whether bpf_link becomes reality before supporting attachment in the library.

It seems like your patch is fairly self contained, do you think it could be a small independent library for the time being, or is there something missing from the public API to make this possible?

[florianl]

Thanks @mythi for demonstrating this easy way to enable tracepoints 👍

I see the concerns @lmb mentioned about the maintenance overhead.
For me, this package is also not limited to network only. BPF link sounds exciting, but might not be available in all the environment, where this package is used.
So, what about documenting this easy way for tracepoints in some kind of readme or example?

[lmb]

@mythi are you still interested in working on this? There is now a link subpackage where this would fit.

[lmb]

Florian added a nice example in #190, I think more than that is out of scope for the library.