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

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

2022-09-01 15:52 (UTC+0300), Boris Ouretskey:
> >
> > 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.  

Theoretically, one can enumerate all capabilities, give all capabilities
except one to the binary, try to run it, and notice which capability removal
leads to a failure. However, `setcap "all=ep $capa-ep" ./binary`
did not give the correct answer to me (why?), so I did it semi-manually.
I created a file with all capabilities listed, /tmp/caps.
The following command sets capabilities from this file
which are not commented-out using #:

sudo setcap $(grep -v "^#" /tmp/caps | tr "\n" "," | sed -e 's/,$/+ep/') ./binary

Then I started commenting parts of /tmp/caps (bisecting actually)
until the error reproduced.

> > [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

Bruce, Anatoly, you know VFIO the best, any suggestions?

> > 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.

An attacker can trick HW to read or write at the specified physical address.
Memory protection is implemented in MMU, and DMA bypasses MMU.
I've no idea how practical this is for penetrating systems,
but even an unintended bug may crash the OS this way or corrupt data.

> > 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 for sharing the experience.
Maybe worth adding to the section about running w/o root privileges.