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: <CAN+4W8hu+zWiWejWtc72WwQb6ydL3U3LXvaFBdc0o826JKzoAQ@mail.gmail.com>
Date: Fri, 20 Oct 2023 14:18:31 +0100
From: Lorenz Bauer <lorenz.bauer@...valent.com>
To: Andrii Nakryiko <andrii@...nel.org>
Cc: 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 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
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.

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

Lorenz