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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzYmZjBd5ps-iKjyxLvQ=iD3z092+M_deV5ze0eJXGoFsg@mail.gmail.com>
Date: Mon, 11 Dec 2023 14:50:08 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: John Fastabend <john.fastabend@...il.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org, netdev@...r.kernel.org, 
	paul@...l-moore.com, brauner@...nel.org, linux-fsdevel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, keescook@...omium.org, 
	kernel-team@...a.com, sargun@...gun.me
Subject: Re: [PATCH bpf-next 3/8] libbpf: further decouple feature checking
 logic from bpf_object

On Mon, Dec 11, 2023 at 1:41 PM John Fastabend <john.fastabend@...il.com> wrote:
>
> Andrii Nakryiko wrote:
> > 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@...nel.org>
> > ---
>
> ...
>
> > 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.

>
> >
> >       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@...il.com>