eBPF maps should be closed, whether used as ebpf_maps:ebpf_map()s or as ebpf_maps:iterator(), but currently close/1 only works for ebpf_map()s, so the original map needs to be kept around after calling iterator/1. This PR allows close/1 to close iterator()s directly.

This PR adds two functions to ebpf_kern:

• branch/5 is a generic branching utility function. It takes a bpf_jmp_op(), two operands (one must be a register, the other can be either a register or an immediate value) and two instruction lists and generates instructions that branch to either list depending on the result of the comparison.
• return/1 is a function for generating instructions that return from the eBPF program with a specific return value, given as either an immediate value or a register whose contents will be set as the return value of the program.

Part of #53

stdlib has maps:take/2, we should have an equivalent ebpf_maps:take/2 for eBPF map. This can possibly be implemented by using the BPF_MAP_LOOKUP_AND_DELETE_ELEM command to bpf(2).

Edit: it appears that Linux only supports BPF_MAP_LOOKUP_AND_DELETE_ELEM for queue and stack typed maps. We can use implement take/2 with get/2 and remove/2 for other types of maps

Part of #41 .

Using integers for registers, offsets and immediate values in ebpf_kern can lead to confusing calls, like

ebpf_kern:mov64_imm(0, 1)

The problem is that it's hard to tell by looking at the code whether that line means r0 = 1 or r1 = 0.

This PR changes the bpf_reg() type the atoms r0, r1, ..., r10 instead of the numeric values of the registers. Hence, after this PR instead of mov64_imm(0, 1) we have

ebpf_kern:mov64_imm(r0, 1)

which does not suffer from the same ambiguity.

Part of #41 This PR merges the ebpf_user:attach_*/2 functions to a single ebpf_user:attach/2 API function. The type of the attach point is determined by the type of the given program.

Part of #41

This PR adds the ebpf_maps module, an API for userspace interaction with eBPF maps that mimics the built-in maps module. Some functions that dealt with eBPF maps are moved from ebpf_user, which is dedicated to eBPF programs, to the new maps module.

Support specifying options to ebpf_user:load via an added Options arg.

Edit: I went ahead and removed the redundant ebpf_user:verify/{2,3} functions while at it as we now get the same functionality with an option for load/3.

Part of #41

The current (initial, v0.1) API is very familiar to those who know eBPF, but it isn't very idiomatic for Erlang programmers. For instance, interaction with eBPF maps could be made a lot more familiar for Erlangers if it was modeled after the OTP maps module.

I want to fix that for v0.2. This library is meant to be used by Erlang programmers, so a familiar API is a priority. Of course, the API should also be as stable as possible, so whatever ends up in v0.2 should be future proof. Although it's still a minor version the goal is for v0.2 to implement a minimal API that will not break in later versions.

Add ebpf_user:test_program/4, which can be used to run a loaded eBPF program with an arbitrary binary() as the input, courtesy of BPF_PROG_TEST_RUN command to bpf(2). This can be generally useful and it's needed for properly testing ebpf_kern.

Currently it is the users responsibility to close(2) eBPF map and program file descriptors via ebpf_{maps,user}:close/1. It would be safer and more convenient if these FDs were to close automatically when no longer needed. There easiest solution would be to use Erlang NIF "resources" for maps/programs instead just passing an integer FD back to BEAM. NIF resources can have a destructor-like callback that is called from the garbage collector when the resource is no longer in use, which is where we can close the FD.

Another path would be to drop the NIFs entirely and use an Erlang port driver to represent maps/programs. That would allow for closing the FDs when the owner Erlang process of the map/program dies.

Add a small binary executable that will be invoked to perform privileged operations, e.g. bpf(2), in behalf of BEAM. That way this helper executable can be given elevated capabilities instead of the BEAM executable, making things much safer in the long term.

Currently ebpf_kern allows you to write eBPF programs, but it doesn't make it particularly easy or Erlang-y. ebpf should supply some higher level API for constructing eBPF programs.

I think that the best solution would be having a fun2bpf parse-transform that takes a literal Erlang fun and outputs a sequence of bpf_instructions, but there are a few steps to cross to get there. For starters it would be nice to have ebpf_kern functions for more common eBPF routines, like loading a value from a map to a specific register, or branching without having to count instructions for the jmp instruction.

This is a big one, so we should start with something small. At the very least ebpf_user:attach/2 needs to support kprobe and tracepoint program types.