Re: Issue setting up the DPDK development with non-privileged user

[Boris Ouretskey <borisusun@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

>
> 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
> <https://stackoverflow.com/questions/73556145/understand-which-capability-exacty-lacks-to-complete-the-operation-in-linux>
> 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
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2867 bytes --]