ebpf | eBPF Utilities, Maps, and more

It's the other way around: it will drop the packet if 0 is returned. From the code:

From the verifier's logs, you have some invalid access here:

I don't believe you are calling the bpf_trace_printk() helper correctly (BPF_FUNC_trace_prink is just an integer, by the way). Its signature, commented in the kernel UAPI header bpf.h or in the bpf-helpers man page, is as follows:

File descriptors when writing your program in user space, but later replaced by pointers to the map by the verifier.

You write your eBPF program in user space, where you don't have any address pointer to the map. So you use a file descriptor for referencing that map for the various operations (lookups, updates, deletes) that your program may run.

If writing your program in C, instead of assembly instructions like you do, this is usually abstracted: The program references the map with a C pointer, but the loader (typically relying on libbpf) performs some relocation step to extract metadata about the map from a dedicated ELF section of the object file, retrieves the file descriptor to the map, and inserts it in the relevant bytecode instructions.

But you are correct: in the kernel, the BPF_FUNC_map_lookup_elem() helper and the like use pointers to the maps, not file descriptors. This is at load time, during verification of the program, that the verifier replaces the file descriptors by the pointers to the memory area associated to the maps (see resolve_pseudo_ldimm64() from kernel/bpf/verifier.c). It is possible to get a pointer at this time: The verifier does have access to the kernel-memory pointers for those maps.

Note that the verifier actually goes even further and, for some map types (hash, arrays), it even replaces the calls to the helpers for map lookups completely, using instead instructions to directly read from the relevant addresses in the map (search for map_gen_lookup for details).

The error is not caused by bpf_trace_prink(), but by the skb accesses that are present in your bytecode only when you call bpf_trace_printk().

Accessing skb->local_ip4 and skb->remote_ip4 is not allowed for programs of types BPF_PROG_TYPE_LWT_OUT, that you use.

See kernel code: The function that checks for valid access for this type returns false for certain offsets or range in skb:

No, this is not possible at the moment.

Once loaded and attached, eBPF programs can call:

• eBPF functions from the same program (eBPF-to-eBPF function calls)
• other eBPF programs, under certain conditions, through tail calls
• other eBPF programs of type BPF_PROG_TYPE_EXT
• kernel function helpers (library of functions defined in the kernel)
• random kernel functions, if they are explicitly marked as callable (should be in Linux 5.13)

It cannot call functions from user space libraries.

TL;DR. You are trying to read arbitrary kernel memory. You need to use bpf_probe_read for that.

Let's have a look at the error logs:

The invalid memory access is on a load from r1. The value in r1 was loaded from memory using the address in r6 as the base. According to the second line, the verifier associates type ctx to r6.

So r6 points to your variable ctx. That variable is special (hence why the verifier has a special ctx type for it). Your BPF program is allowed to access memory pointed by that variable as long as its bounded (the exact bound depends on the program type).

It will not be possible to obtain the string version of pathname using perf tools in this case.

When a userspace utility calls perf_even_open syscall with a request to monitor tracepoint events, such as the one you are trying to monitor with syscalls:sys_enter_unlinkat, a 'perf probe' function is attached to the tracepoint. You can see the probe function here.

The probe function allocates a perf buffer and validates the allocated buffer after which it invokes a bpf program.

This bpf program needs to know the 'format' of the static tracepoint event, since it needs to understand what is the structure of the binary trace output in the perf ring buffer.

The format of the event is defined in the /sys/kernel/debug/tracing/events/syscalls/sys_enter_unlinkat/format file, for your case.

If you look at this file, you will see that perf script reports the output as per the print fmt entry in the field.

There was a talk on this topic by Bryce Kahle at the eBPF Summit. It's the most complete answer to this question I'm aware of.

To summarize, you have several options:

• Rely on kernel.bpf_stats_enabled statistics collected by the kernel.
• Use bpftool prog profile.
• Use BPF_PROG_TEST_RUN hook, e.g., via bpftool prog run.

The talk doesn't mention one last option: you can now attach BPF program at the entry and exit of other BPF programs with BPF trampoline.