Thread (26 messages) 26 messages, 5 authors, 2023-12-12

Re: [PATCH bpf-next 3/8] libbpf: further decouple feature checking logic from bpf_object

From: Andrii Nakryiko <hidden>
Date: 2023-12-11 22:50:22
Also in: bpf, linux-fsdevel, linux-security-module

On Mon, Dec 11, 2023 at 1:41 PM John Fastabend [off-list ref] wrote:
Andrii Nakryiko wrote:
quoted
Add feat_supported() helper that accepts feature cache instead of
bpf_object. This allows low-level code in bpf.c to not know or care
about higher-level concept of bpf_object, yet it will be able to utilize
custom feature checking in cases where BPF token might influence the
outcome.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
...
quoted
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index a6b8d6f70918..af5e777efcbd 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -637,6 +637,7 @@ struct elf_state {
 };

 struct usdt_manager;
+struct kern_feature_cache;

 struct bpf_object {
      char name[BPF_OBJ_NAME_LEN];
@@ -5063,17 +5064,14 @@ static struct kern_feature_desc {
      },
 };

-bool kernel_supports(const struct bpf_object *obj, enum kern_feature_id feat_id)
+bool feat_supported(struct kern_feature_cache *cache, enum kern_feature_id feat_id)
 {
      struct kern_feature_desc *feat = &feature_probes[feat_id];
-     struct kern_feature_cache *cache = &feature_cache;
      int ret;

-     if (obj && obj->gen_loader)
-             /* To generate loader program assume the latest kernel
-              * to avoid doing extra prog_load, map_create syscalls.
-              */
-             return true;
+     /* assume global feature cache, unless custom one is provided */
+     if (!cache)
+             cache = &feature_cache;
Why expose a custom cache at all? Where would that be used? I guess we are
looking at libbpf_internal APIs so maybe not a big deal.
bpf_object with token_fd set will have to use a separate non-global
feature cache. Couple that with me moving this code into a separate
features.c file in one of the next patches, we need to have some
internal interface to make this happen.

Also, bpf.c is also using feature detectors, but today they all use
unprivileged program types, so I didn't add custom feature_cache there
just yet. But if in the future we have more complicated feature
detectors that will rely on privileged programs/maps, we'd need to
pass custom feature_cache from bpf.c as well.
quoted
      if (READ_ONCE(cache->res[feat_id]) == FEAT_UNKNOWN) {
              ret = feat->probe();
@@ -5090,6 +5088,17 @@ bool kernel_supports(const struct bpf_object *obj, enum kern_feature_id feat_id)
      return READ_ONCE(cache->res[feat_id]) == FEAT_SUPPORTED;
 }
Acked-by: John Fastabend <john.fastabend@gmail.com>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help