From: Maryam Tahhan <mtahhan@redhat.com>
To: "Koikkara Reeny, Shibin" <shibin.koikkara.reeny@intel.com>,
"ferruh.yigit@amd.com" <ferruh.yigit@amd.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"lihuisong@huawei.com" <lihuisong@huawei.com>,
"fengchengwen@huawei.com" <fengchengwen@huawei.com>,
"liuyonglong@huawei.com" <liuyonglong@huawei.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [v1] net/af_xdp: enable a sock path alongside use_cni
Date: Fri, 1 Dec 2023 10:20:25 +0000 [thread overview]
Message-ID: <6fd52527-ba49-4a83-a333-a0a353020686@redhat.com> (raw)
In-Reply-To: <DM6PR11MB3995A1F60439980E4717CE81A281A@DM6PR11MB3995.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]
[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).
[-- Attachment #2: Type: text/html, Size: 5352 bytes --]
next prev parent reply other threads:[~2023-12-01 10:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 9:13 Maryam Tahhan
2023-11-30 12:14 ` Koikkara Reeny, Shibin
2023-11-30 12:32 ` Maryam Tahhan
2023-11-30 13:55 ` Koikkara Reeny, Shibin
2023-11-30 13:56 ` Koikkara Reeny, Shibin
2023-11-30 14:17 ` Maryam Tahhan
2023-12-01 9:55 ` Koikkara Reeny, Shibin
2023-12-01 10:20 ` Maryam Tahhan [this message]
2023-12-01 10:49 ` Koikkara Reeny, Shibin
2023-11-30 14:30 ` Maryam Tahhan
2023-12-01 10:26 ` David Marchand
2023-12-01 10:31 ` Maryam Tahhan
2023-12-01 10:33 ` Maryam Tahhan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6fd52527-ba49-4a83-a333-a0a353020686@redhat.com \
--to=mtahhan@redhat.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=lihuisong@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=shibin.koikkara.reeny@intel.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).