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 118E2A0032 for ; Thu, 1 Sep 2022 14:52:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E679A40C35; Thu, 1 Sep 2022 14:52:36 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 471E340695 for ; Thu, 1 Sep 2022 14:52:35 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id f12so16818229plb.11 for ; Thu, 01 Sep 2022 05:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=TNgF4MKhcLQmMeVomUrc28+AAm/Dl1UAtjr26o7oV7k=; b=lOXKcceGjOUTQzdQYvlbZ5hiD70jqK7HVaWKBVUtM968tHMy98/WJBPraoLJzjzXsJ ezK2ftUwROwhOj7QWqim7D2oiSGG9BQ05QE88WZCPUYx5T/9tI8/8QIroOzEIJBbwGoz M8shUa9devpPUQ02jDFJdakEXCdnmHi04jzd4h+5u/5II3JN1YscXqJ9VKXG0Y5BTaCY zWZqAct82FDOSVT3uLj8iQqqp0/z+hk71jd0D+BdlxMrtoZBjh3yEsikl3G/SoyYyu1h 5aH0tYmg1Y2yrU7peUINERkB3zf36RIICJ3XeutEPc8sjA9COD4WKzG/AhamMhPlbE99 Su7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=TNgF4MKhcLQmMeVomUrc28+AAm/Dl1UAtjr26o7oV7k=; b=8Q1iLnWmbcSmnVYe87g4o+EV3xltNzgOFkg/FvZ/+SUzqqIL9gHV7n9Qy13w/P8obJ pUAy8nULaIpt7M3093Q33HU/JT4S8AWm4FnHZS4/8kHnb82gMM+IIs/F9S+1DEqgxNAU ZexcYLLpkT6Fbye7BiZti0U07HdnWw7iuB8LxkJqUY+ZesQ3lCpMBz+teTzQmQ6NyGTL yulBCl0k8NbmF6EPLMA0nh3rzBaACQHPFVt7+XD2U78g+RR+3w6jgku3IpNIobzHJkA0 ovaE0K44xI3w2eoyWV9i0/DSfT5erjM1sE66Tt1MyJD8SLZ+BEti2hJaems28zxsal12 cDpQ== X-Gm-Message-State: ACgBeo2tFsmP7pO0Zf6xWkxPm3CkogOOpI5NPVh+VX8aiPXFyXhYxgon RNqLR0uPmueAeOyyEZe2ImFCf351rV9bmsMxVNLNeY+QcMv6vg== X-Google-Smtp-Source: AA6agR5XatRx4UzGElrYZkmOyddzGc3onqXPYidBpY6oNNz/AyO6Zei9CcacgVfM7kd0/dKHO+BlQDsNFHa8EOiayOE= X-Received: by 2002:a17:90a:ab8d:b0:1fa:af75:e4ed with SMTP id n13-20020a17090aab8d00b001faaf75e4edmr8741275pjq.119.1662036754311; Thu, 01 Sep 2022 05:52:34 -0700 (PDT) MIME-Version: 1.0 References: <20220831190158.44dd76de@sovereign> In-Reply-To: <20220831190158.44dd76de@sovereign> From: Boris Ouretskey Date: Thu, 1 Sep 2022 15:52:23 +0300 Message-ID: Subject: Re: Issue setting up the DPDK development with non-privileged user To: Dmitry Kozlyuk Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000582ebd05e79d16ed" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000582ebd05e79d16ed Content-Type: text/plain; charset="UTF-8" > > Dmitry, > Thanks a lot for the reply. > 1. The things look better now, but now we still have some capabilities > left out in order for the program to run. I am myself not a kernel > programmer and asked on stackoverflow > > the question on how can we deduce the exact capability that failed the > check in kernel. Otherwise the process of finding the exact set can be very > irritating. May be someone here will have the idea better than guessing for > user space developers. > > ----- > [user1@dredd examples]$ sudo setcap > cap_ipc_lock,cap_sys_admin,cap_dac_override+ep ./dpdk-helloworld > [sudo] password for user1: > [user1@dredd examples]$ ./dpdk-helloworld > EAL: Detected CPU lcores: 4 > EAL: Detected NUMA nodes: 1 > EAL: Detected static linkage of DPDK > EAL: Multi-process socket /run/user/1000/dpdk/rte/mp_socket > EAL: Selected IOVA mode 'PA' > EAL: VFIO support initialized > EAL: Cannot open /dev/vfio/noiommu-0: Operation not permitted > EAL: Failed to open VFIO group 0 > EAL: Requested device 0000:00:08.0 cannot be used > EAL: Cannot open /dev/vfio/noiommu-1: Operation not permitted > EAL: Failed to open VFIO group 1 > EAL: Requested device 0000:00:09.0 cannot be used > TELEMETRY: No legacy callbacks, legacy socket not created > hello from core 1 > hello from core 2 > hello from core 3 > hello from core 0 > > 2. Thanks a lot for pointing out how it works. Regarding your second note, > In my understanding, knowing physical addresses does not help any user > process lacking the corresponding privileges. Because mapping and read > permission are enforced by kernel & hardware, even knowing the physical > memory address would not help regular process reading or updating it unless > the physical page was mapped by the kernel into process virtual space with > proper permission. > > In addition it turns out that if one would like to debug DPDK or any other > executable using a special capabilities set, this set must be duplicated in > gdb (at least that's how it worked for me), otherwise it spawns debugee > with reduced capabilities set ( I guess by means of bound set). If someone > using VSCODE remote connection debug than also > > > Thanks again for the help > > > > --000000000000582ebd05e79d16ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dmitry,
Thanks a lot for the=C2=A0reply.=C2=A0
1. = The things look better now, but now we still have some capabilities left ou= t in order for the program to run. I am myself not a kernel programmer and = asked on stackove= rflow the question on how can we deduce the exact capability that faile= d the check in kernel. Otherwise the process of finding the=C2=A0exact set = can be very irritating. May be someone here will have the idea better than = guessing for user space developers.
=C2=A0

-----
[user1@dredd examples]= $ sudo setcap cap_ipc_lock,cap_sys_admin,cap_dac_override+ep ./dpdk-hellowo= rld
[sudo] password for user1:
[user1@dredd examples]$ ./dpdk-hellowo= rld
EAL: Detected CPU lcores: 4
EAL: Detected NUMA nodes: 1
EAL: D= etected static linkage of DPDK
EAL: Multi-process socket /run/user/1000/= dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: VFIO sup= port initialized
EAL: Cannot open /dev/vfio/noiommu-0: Operation not per= mitted
EAL: Failed to open VFIO group 0
EAL: Requested device 0000:00= :08.0 cannot be used
EAL: Cannot open /dev/vfio/noiommu-1: Operation not= permitted
EAL: Failed to open VFIO group 1
EAL: Requested device 000= 0:00:09.0 cannot be used
TELEMETRY: No legacy callbacks, legacy socket n= ot created
hello from core 1
hello from core 2
hello from core 3hello from core 0

2. Thanks a lot for pointing=C2=A0out how it wor= ks. Regarding your second note, In my understanding, knowing=C2=A0physical = addresses does not help any user process lacking the corresponding privileg= es. Because mapping and read permission are enforced by kernel & hardwa= re, even knowing the physical memory address would not help regular process= reading or updating it unless the physical page=C2=A0 was mapped by the ke= rnel into process virtual space with proper=C2=A0permission.=C2=A0=C2=A0
In addition it turns out that if one=C2=A0would like to debug DPDK or = any other executable using a special capabilities set, this set must be dup= licated in gdb (at least that's how it worked for me), otherwise it spa= wns debugee with reduced capabilities set ( I guess by means of bound set).= If someone using VSCODE remote connection debug than also=C2=A0

=C2=A0

Thanks again for the help



--000000000000582ebd05e79d16ed--