[v1] net/af_xdp: enable a sock path alongside use_cni

Maryam Tahhan mtahhan at redhat.com
Fri Dec 1 11:20:25 CET 2023


[snip]
>
>               Prerequisites
>
>             @@ -224,7 +225,6 @@ Howto run dpdk-testpmd with CNI plugin:
>
>                         capabilities:
>
>                            add:
>
>                              - CAP_NET_RAW
>
>             -               - CAP_BPF
>
>     Why the CAP_BPF is removed?
>
> Good question. It's removed because in our case CAP_BPF is only needed 
> when we want to load or unload the XDP program on the interface inside 
> the Pod. In our case the CNI is loading the xdp program on the 
> interface and then we are doing a handshake to get the xskmap file 
> descriptor and so we don't need the CAP_BPF.
>
> You will find a detailed listing of the permissions used at different 
> stages when utilizing an XDP prog in this article 
> https://next.redhat.com/2023/07/18/using-ebpf-in-unprivileged-pods/
>
> I'm currently also working on enabling pinned map sharing with the 
> af_xdp vdev eal arguments so we can integrate with bpfman for 
> centralized BPF program lifecycle management [currently under test].
>
> Correct me if I am wrong, Don’t we still need the CAP_BPF for bpf 
> operations?
>
The only BPF operation in the Pod (when using the AF_XDP CNI) is 
interacting with the BPF maps via bpf_map_update_elem().

There's no BPF load/unload operations when you are using the AF_XDP DP 
and CNI (it does this for you) similar to what bpfman is doing in [1]. 
To interact with BPF maps you don't need CAP_BPF since the 5.19 Kernel 
please see [2], in addition to the previous links. In other words the 
only time you should need cap_bpf to access a map is if your kernel is 
<= 5.18. Which was the note I was referring to when I said I would 
update the documentation.

I've tested this patch in pod on Fedora 38 Kernel version: 
6.5.12-200.fc38.x86_64 and there you don't need CAP_BPF.

Additionally Ubuntu 22.04 LTS is now shipping with a 6.2 Kernel [3], so 
you will not need it there either.

We don't want to give the pods more permissions than they need. CAP_BPF 
is in IMO an elevated permission.

> If CAP_BPF is not need so do we need the CAP_NET_RAW also?
>
You need the CAP_NET_RAW to create the AF_XDP socket.



> [snip]
>

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=c8644cd0efe7 


[2] 
https://bpfd.dev/developer-guide/linux-capabilities/#removing-cap_bpf-from-bpfman-clients

[3] 
https://tuxcare.com/blog/ubuntu-22-04-3-is-here-with-linux-kernel-6-2/#:~:text=Initially%20released%20on%20April%2021,Ubuntu%2023.04%20(Lunar%20Lobster).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20231201/6af70034/attachment.htm>


More information about the dev mailing list