[PATCH v8 bpf-next 00/18] BPF token and BPF FS-based delegation

[Andrii Nakryiko]

On Fri, Oct 20, 2023 at 6:18 AM Lorenz Bauer <lorenz.bauer at isovalent.com> wrote:
>
> On Mon, Oct 16, 2023 at 7:03 PM Andrii Nakryiko <andrii at kernel.org> wrote:
> ...
> > This patch set adds a basic minimum of functionality to make BPF token idea
> > useful and to discuss API and functionality. Currently only low-level libbpf
> > APIs support creating and passing BPF token around, allowing to test kernel
> > functionality, but for the most part is not sufficient for real-world
> > applications, which typically use high-level libbpf APIs based on `struct
> > bpf_object` type. This was done with the intent to limit the size of patch set
> > and concentrate on mostly kernel-side changes. All the necessary plumbing for
> > libbpf will be sent as a separate follow up patch set kernel support makes it
> > upstream.
> >
> > Another part that should happen once kernel-side BPF token is established, is
> > a set of conventions between applications (e.g., systemd), tools (e.g.,
> > bpftool), and libraries (e.g., libbpf) on exposing delegatable BPF FS
> > instance(s) at well-defined locations to allow applications take advantage of
> > this in automatic fashion without explicit code changes on BPF application's
> > side. But I'd like to postpone this discussion to after BPF token concept
> > lands.
>
> In the patch set you've extended MAP_CREATE, PROG_LOAD and BTF_LOAD to
> accept an additional token_fd. How many more commands will need a
> token as a context like this? It would cause a lot of churn to support

There are few more commands that do capable() checks (GET_NEXT_ID and
GET_FD_BY_ID commands, TASK_QUERY, maybe few others), so if those
would be necessary to delegate, we can probably add token support
there as well. Other than that LINK_CREATE seems like a likely
candidate in the future. This will probably be driven by concrete
customer use cases.

> many BPF commands like this, since every command will have token_fd at
> a different offset in bpf_attr. This means we need to write extra code
> for each new command, both in kernel as well as user space.

Yes, but that's generally true for anything else added to BPF syscall
(like verifier log, for example). Luckily it's not really a lot of
commands and definitely not a lot of code.

>
> Could we pass the token in a way that is uniform across commands?
> Something like additional arg to the syscall or similar.

Adding a new argument means adding a new syscall (bpf2()) due to
backwards compatibility requirements. Adding bpf2() syscall means
adding even more code to all existing libraries to support them (and
still keeping backwards compatibility with bpf() syscall).

It doesn't really seem worth it just for passing token_fd to a few
commands, IMO.

>
> Lorenz