map_fd | map_fd workaround for ld_classic on OS X

I don't know what the theoretical answer is according to the standard and the GNU documentation, as they're not very detailed, but here's an extensive experimental answer.

For my experiment I wrote the following file:

align.c:

TL;DR. Qeole is correct, you first need to make sure you are using one of the BPF program types allowed for unprivileged users. You also need to check your sysctl settings. Finally, your current program has a pointer leak that should be fixed before it is loaded by an unprivileged users.

The kernel allows unprivileged users to load only two types of BPF programs, BPF_PROG_TYPE_SOCKET_FILTER and BPF_PROG_TYPE_CGROUP_SKB. You can see the check in the kernel for that condition in kernel/bpf/syscall.c.

The kernel.unprivileged_bpf_disabled sysctl controls whether unprivileged users can load eBPF programs. It is unfortunately set to 0 (allow loading) on major distributions.

The context placed in BPF_REG_1 before the program starts is not a pointer to the beginning of the data. Instead, it is a pointer to a struct __sk_buff defined in the UAPI headers as follows:

There is a comment in a function from the kernel code called when you try to retrieve information about your program, stating:

/* If we're handed a bigger struct than we know of, ensure all the unknown bits are 0 - i.e. new user-space does not rely on any kernel feature extensions we don't know about yet. [...] */

I think this is what you hit in your case. Your libbpf version might use some attributes in struct bpf_prog_info that the kernel is not aware of.

To ensure that the kernel accepts it, simply try to zero-initialise your struct:

The BPF and XDP Reference Guide from Cilium has an excellent explanation for this problem.

In short, this is because the compiler automatically adds some padding to your key and moves it to the stack before calling the map update helper. But when this program is checked, the verifier realises there are some uninitialised bytes it is not aware of, and rejects the program.

You could fix it by packing your struct, although this also has some disadvantages. The recommended solution is to manually pad your key to have it fit on a multiple of four bytes. From OP's edit:

If you know you have just one element, the easiest is probably to go for an array map. In that case, you can trivially access your map entry by its index in the array: 0.

If you were to do that, the size of the key would be the size of a 4-byte integer (sizeof(uint32_t)), which are always used for array indices. The size of the value would be the size you need to store your port number: very likely a sizeof(uint16_t).

Then you can read/write from your BPF program by calling the relevant BPF helper functions: bpf_map_lookup_elem() or bpf_map_update_elem() (see man page for details). They are usually defined in bpf_helpers.h which is not usually installed on your system, you can find versions of it in bcc or kernel repo.

From user space, you would update the entry by using the bpf() system call, with its relevant commands: BPF_MAP_LOOKUP_ELEM() and BPF_MAP_UPDATE_ELEM() (see man page). But you don't necessarily have to re-implement the calls yourself: if you write a program, you should probably have a look at libbpf that provides wrappers. If you want to update your map from the command line, this is easy to do with bpftool (see man page), something like bpftool map update key 0 0 0 0 value 0x37 0x13 (update) or bpftool map lookup key 0 0 0 0 (lookup).