Andrii Nakryiko wrote: > Add fuller support for BPF token in high-level BPF object APIs. This is the > most frequently used way to work with BPF using libbpf, so supporting BPF > token there is critical. > > Patch #1 is improving kernel-side BPF_TOKEN_CREATE behavior by rejecting to > create "empty" BPF token with no delegation. This seems like saner behavior > which also makes libbpf's caching better overall. If we ever want to create > BPF token with no delegate_xxx options set on BPF FS, we can use a new flag to > enable that. > > Patches #2-#5 refactor libbpf internals, mostly feature detection code, to > prepare it from BPF token FD. > > Patch #6 adds options to pass BPF token into BPF object open options. It also > adds implicit BPF token creation logic to BPF object load step, even without > any explicit involvement of the user. If the environment is setup properly, > BPF token will be created transparently and used implicitly. This allows for > all existing application to gain BPF token support by just linking with > latest version of libbpf library. No source code modifications are required. > All that under assumption that privileged container management agent properly > set up default BPF FS instance at /sys/bpf/fs to allow BPF token creation. > > Patches #7-#8 adds more selftests, validating BPF object APIs work as expected > under unprivileged user namespaced conditions in the presence of BPF token. > > Patch #9 extends libbpf with LIBBPF_BPF_TOKEN_PATH envvar knowledge, which can > be used to override custom BPF FS location used for implicit BPF token > creation logic without needing to adjust application code. This allows admins > or container managers to mount BPF token-enabled BPF FS at non-standard > location without the need to coordinate with applications. > LIBBPF_BPF_TOKEN_PATH can also be used to disable BPF token implicit creation > by setting it to an empty value. Patch #10 tests this new envvar functionality. > > v2->v3: > - move some stray feature cache refactorings into patch #4 (Alexei); > - add LIBBPF_BPF_TOKEN_PATH envvar support (Alexei); We can do same thing from golang ebpf lib when we get around to adding it. Looks good to me. I see its merged but, Ack for me. > v1->v2: > - remove minor code redundancies (Eduard, John); > - add acks and rebase. > > Andrii Nakryiko (10): > bpf: fail BPF_TOKEN_CREATE if no delegation option was set on BPF FS > libbpf: split feature detectors definitions from cached results > libbpf: further decouple feature checking logic from bpf_object > libbpf: move feature detection code into its own file > libbpf: wire up token_fd into feature probing logic > libbpf: wire up BPF token support at BPF object level > selftests/bpf: add BPF object loading tests with explicit token > passing > selftests/bpf: add tests for BPF object load with implicit token > libbpf: support BPF token path setting through LIBBPF_BPF_TOKEN_PATH > envvar > selftests/bpf: add tests for LIBBPF_BPF_TOKEN_PATH envvar > > kernel/bpf/token.c | 10 +- > tools/lib/bpf/Build | 2 +- > tools/lib/bpf/bpf.c | 9 +- > tools/lib/bpf/btf.c | 7 +- > tools/lib/bpf/elf.c | 2 - > tools/lib/bpf/features.c | 478 +++++++++++++++ > tools/lib/bpf/libbpf.c | 573 ++++-------------- > tools/lib/bpf/libbpf.h | 37 +- > tools/lib/bpf/libbpf_internal.h | 36 +- > tools/lib/bpf/libbpf_probes.c | 8 +- > tools/lib/bpf/str_error.h | 3 + > .../testing/selftests/bpf/prog_tests/token.c | 347 +++++++++++ > tools/testing/selftests/bpf/progs/priv_map.c | 13 + > tools/testing/selftests/bpf/progs/priv_prog.c | 13 + > 14 files changed, 1065 insertions(+), 473 deletions(-) > create mode 100644 tools/lib/bpf/features.c > create mode 100644 tools/testing/selftests/bpf/progs/priv_map.c > create mode 100644 tools/testing/selftests/bpf/progs/priv_prog.c > > -- > 2.34.1 > >
