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. > > 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. > > 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. [...] > Maybe we can have more discussion? We sure need more discussion before shipping any changes for this topic. Thanks, Song
