netdev - Re: [PATCH bpf-next 0/8] BPF token support in libbpf's BPF object

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: <CAEf4BzbKJDkFbKo0UVGctZ8in9eD+abgncTXHFh2oZg1Gn21QA@mail.gmail.com>
Date: Mon, 11 Dec 2023 10:21:30 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Eduard Zingerman <eddyz87@...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 0/8] BPF token support in libbpf's BPF object

On Sun, Dec 10, 2023 at 7:30 AM Eduard Zingerman <eddyz87@...il.com> wrote:
>
> On Thu, 2023-12-07 at 10:54 -0800, 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.
>
> fwiw, I've read through this patch-set and have not noticed any issues,
> all seems good to me. Not sure if that worth much as I'm not terribly
> familiar with code base yet.

Every extra pair of eyes is worth it :) Not finding anything obviously
broken is still a good result, thanks!

>
> [...]