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

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: <CAEf4BzbK2JkJwcwtXzhnazxT7dasjpSbScOoE=N9wkcepJu81w@mail.gmail.com>
Date: Fri, 20 Oct 2023 09:25:15 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Lorenz Bauer <lorenz.bauer@...valent.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org, netdev@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-security-module@...r.kernel.org, 
	keescook@...omium.org, brauner@...nel.org, lennart@...ttering.net, 
	kernel-team@...a.com, sargun@...gun.me
Subject: Re: [PATCH v8 bpf-next 00/18] BPF token and BPF FS-based delegation

On Fri, Oct 20, 2023 at 6:18 AM Lorenz Bauer <lorenz.bauer@...valent.com> wrote:
>
> On Mon, Oct 16, 2023 at 7:03 PM Andrii Nakryiko <andrii@...nel.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