Re: [RFC PATCH bpf-next 2/7] bpf: Add enum bpf_capability

[Juntong Deng]

On 2025/1/17 21:40, Song Liu wrote:
> On Fri, Jan 17, 2025 at 11:37 AM Juntong Deng <juntong.deng@xxxxxxxxxxx> wrote:
> >
> [...]
> > Thanks for your reply.
> >
> > I am not sure if BPF capabilities is a good approach.
> >
> > But we currently need filters because we register all kfuncs to program
> > types, which are too coarse-grained, so we need additional filters for
> > further filtering (make the granularity finer).
> >
> > We added struct btf_kfunc_hook_filter and added filter logic in
> > btf_populate_kfunc_set, __btf_kfunc_id_set_contains, essentially to
> > mitigate the problem of coarse-grained permissions management.
> >
> > If we register all kfuncs to BPF capabilities, then we will no longer
> > need additional filters for further filtering because BPF capabilities
> > is already fine-grained.
>
> bpf_capabilities_adjust is the filter function with a different name.
> So the extra capability concept doesn't give us much benefit.

Yes, you are right, I realized this too.

Especially since bpf_capabilities_adjust is procedural, adjusting
capabilities based on different contexts is essentially no different
from filters.

Although we can use BTF_LIST to store the capabilities of different
contexts in BTF sections, making the BPF capabilities corresponding
to different contexts declarative.

But it seems not worth it, because the filter is more straightforward.

I totally agree that BPF capabilities will not give us much benefit in
solving the SCX context problem.

> > Would it be a better idea for us to let each kfunc have its own
> > capability attribute?
>
> This is no different to the BPF helper function ID, which turned
> out to be not scalable.

There still seems to be a difference? BPF capabilities are not
one-to-one with kfuncs, and multiple kfuncs can be bound to one
BPF capability.

BPF capabilities are more like fine-grained versions of program types.

> > In addition, BPF capabilities seem like a extensible idea. Would it be
> > valuable if we make other features of BPF (BPF helpers, BPF maps, even
> > attach targets) have their own capability attributes and can be managed
> > uniformly through BPF capabilities?
> >
> > For example, if a bpf program has BPF_CAP_TRACING, then it will be able
> > to use kprobes and can use tracing related kfuncs and helpers. If a bpf
> > program has BPF_CAP_SOCK then it will be able to use
> > BPF_MAP_TYPE_SOCKMAP and use socket related kfuncs and helpers.
> >
> > In other words, if we add a general internal permissions management
> > system to the BPF subsystem, would it be valuable?
> >
> > BPF is general, and it is foreseeable that BPF will be applied to more
> > and more subsystems and scenarios, so maybe a general fine-grained
> > permissions management would be better?
> >
> > Fine-grained permissions management will bring potential flexibility
> > in configurability.
> >
> > For example, if a system administrator wants to open the features of the
> > HID-BPF driver to users, but the system administrator does not want to
> > open other BPF features to users, such as sched_ext.
>
> This appears to be a totally separate topic.

Although I am not sure, I guess general fine-grained permissions
management might still be valuable (not necessarily BPF capabilities).

I found that Andrii Nakryiko implemented something similar in
BPF Token[0].

Similar to SCX, BPF features are fine-grained through masks to restrict
only part of the BPF features to be opened.

This seems to indicate that the demand for making BPF permissions
management fine-grained has always existed, and the demand for opening
only part of the BPF features will reappear in different forms.

Maybe we do need a general fine-grained permissions management solution?

If Andrii saw this email, could you please join the discussion?

[0]: https://lwn.net/Articles/947173/

> [...]
>
> > Maybe we can have more discussion?
>
> We sure need more discussion before shipping any changes for this
> topic.
>
> Thanks,
> Song