From: Yuan Chen <[email protected]>
v2:
https://lore.kernel.org/bpf/caef4bzbbmtfanjt4brtem3bxarokrrtdfxwpny9hmmt_lfa...@mail.gmail.com/
When BPF programs reference global variables (e.g., struct_ops
programs with global data), libbpf creates internal ARRAY maps to
back them. This depends on FEAT_GLOBAL_DATA, which is gated by
feature probes that load test programs (SOCKET_FILTER, KPROBE, etc.)
into the kernel.
In a user namespace with an implicit BPF token, two problems arise:
1. bpf_object__probe_loading() passes the token fd to test program
loads. When the token's allowed program type mask excludes the
probe types, the kernel drops the token reference, causing
subsequent struct_ops loads to fail because the token object
has been released.
2. Feature probes hardcode SOCKET_FILTER/TRACEPOINT as the program
type for their test loads. When the token restricts program
types, these loads fail and features (FEAT_GLOBAL_DATA, etc.)
are incorrectly reported as missing, so internal maps for global
data are never created.
Together, these cause struct_ops programs referencing global data
to fail verification with "fd X is not pointing to valid bpf_map".
This series fixes both issues:
Patch 1: Skip bpf_object__probe_loading() entirely when a BPF
token is present. Token creation itself proves the
kernel BPF subsystem works.
Acked-by: Mykyta Yatsenko <[email protected]>
Patch 2: Fetch the first probeable program type from the token's
allowed_progs mask instead of hardcoding SOCKET_FILTER
or TRACEPOINT. When no probeable type exists, return
success (token creation proves the BPF subsystem works).
v3 changes:
- Drop the selftest patch (ARRAY map type addition) — no longer needed.
- Patch 2: implement reviewer's suggestion to fetch the first supported
program type from the token instead of blanket skipping. Use an
18-type probeable list of types known to accept trivial "return 0"
programs without specific expected_attach_type. When no probeable
type exists (e.g. only STRUCT_OPS), assume the feature is supported.
v2 changes:
- Replace the workaround of granting SOCKET_FILTER/KPROBE permissions
in the token with a proper fix at the feature probe level in libbpf.
Yuan Chen (2):
libbpf: Skip bpf_object__probe_loading() when BPF token is in use
libbpf: fetch probeable prog type from token for feature probes
tools/lib/bpf/features.c | 97 ++++++++++++++++++++++++++++++++++++++++++++----
tools/lib/bpf/libbpf.c | 10 ++---
2 files changed, 93 insertions(+), 14 deletions(-)
--
2.54.0
