From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 123134341B; Fri, 1 Dec 2023 11:20:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E644342F09; Fri, 1 Dec 2023 11:20:30 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id E6B0F402B9 for ; Fri, 1 Dec 2023 11:20:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701426029; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6197qySpEvcwI0gju5XCTiamgYsWbFQMdOAHMav3BWQ=; b=N6+wgtkLbpxNNfN99uxdESRzW1hi+PU89u/gMHjqPTV4xKKB3FyUW7T9KTxAo+0RNnpBAm 3TCBsze2Ff8dCy0C4p0MZ6yuUIk1P7nAFx72f0aNsI1WNsMzxWHEsT4KUAvIGiWvVbZP1u RIIe+hUxAA1bLN5BiY1R2Ah3FNeQO9g= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-103-AtoExkOGOlKa5ZkSiV6i1g-1; Fri, 01 Dec 2023 05:20:27 -0500 X-MC-Unique: AtoExkOGOlKa5ZkSiV6i1g-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40b4096abc8so14193385e9.0 for ; Fri, 01 Dec 2023 02:20:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701426027; x=1702030827; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=6197qySpEvcwI0gju5XCTiamgYsWbFQMdOAHMav3BWQ=; b=L3IB/UKCf3ZLAjFl3odM6azr9dKn9avxbOpwdtN4+Fs1oVQKW966wHmGfcaVFDAclx SpeqjDHBhnA5xu6iPHNHbaFqxMfs14yOuQevN0ySbM6t1yLnBUHySGJ+KomNon/BELeu heRiZHEvP9FLfmZpOeMajmALYTV5pPpRIobiRFmCLJDy/FUo2nKiUS1sIFX+7flq/VJI CUqIpGwJ7Xmm6fX7Hptp+cIUeMDOCEjx5uLY/yCPHjfcUuKS1Og/8Hl9fO6g2uapXbKT xYBy3+/SnaySEMMSwjHdMR/gKfXTYKtmUOov6OYQJRUfdy1FwNjyG0rNPHzkDSfIgACa VQHQ== X-Gm-Message-State: AOJu0YyB40+HwED9/5oNswf22bUfBr1Mzyf8Xep8Ae5EYN/rJZwPQ2y9 hoMUUY8ikgwaXmR9bWtFcbgU1H4+h1v5KUgg04iFTQ20EE7JHtlsQM6qV2rz5X4tuafI1BwU9eZ Mr+A= X-Received: by 2002:a05:600c:364d:b0:40b:5e21:c5c7 with SMTP id y13-20020a05600c364d00b0040b5e21c5c7mr222937wmq.149.1701426026830; Fri, 01 Dec 2023 02:20:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IH9+svMrQ6UogWGUF7rWG008+bkFKPoq8iAzUcDs//Nvl3NXoPVOxpbd8TZMsrHBQOxH3dtoA== X-Received: by 2002:a05:600c:364d:b0:40b:5e21:c5c7 with SMTP id y13-20020a05600c364d00b0040b5e21c5c7mr222929wmq.149.1701426026337; Fri, 01 Dec 2023 02:20:26 -0800 (PST) Received: from [192.168.0.12] ([78.18.22.228]) by smtp.gmail.com with ESMTPSA id fb13-20020a05600c520d00b0040b3e7569fcsm8515236wmb.11.2023.12.01.02.20.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Dec 2023 02:20:26 -0800 (PST) Message-ID: <6fd52527-ba49-4a83-a333-a0a353020686@redhat.com> Date: Fri, 1 Dec 2023 10:20:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v1] net/af_xdp: enable a sock path alongside use_cni To: "Koikkara Reeny, Shibin" , "ferruh.yigit@amd.com" , "stephen@networkplumber.org" , "lihuisong@huawei.com" , "fengchengwen@huawei.com" , "liuyonglong@huawei.com" Cc: "dev@dpdk.org" References: <20231130091332.2315572-1-mtahhan@redhat.com> <6c78956f-b3f6-483c-8072-f0e6d8610986@redhat.com> From: Maryam Tahhan In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------W0fwD0Jiv3SaSt0MCHNUKW4f" Content-Language: en-US X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org This is a multi-part message in MIME format. --------------W0fwD0Jiv3SaSt0MCHNUKW4f Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit [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). --------------W0fwD0Jiv3SaSt0MCHNUKW4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit [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).

--------------W0fwD0Jiv3SaSt0MCHNUKW4f--