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