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
