Aaron Conole, Feb 22, 2023 at 18:07: > Open vSwitch generally tries to let the underlying operating system > managed the low level details of hardware, for example DMA mapping, > bus arbitration, etc. However, when using DPDK, the underlying > operating system yields control of many of these details to userspace > for management. > > In the case of some DPDK port drivers, configuring rte_flow or even > allocating resources may require access to iopl/ioperm calls, which > are guarded by the CAP_SYS_RAWIO privilege on linux systems. These > calls are dangerous, and can allow a process to completely compromise > a system. However, they are needed in the case of some userspace > driver code which manages the hardware (for example, the mlx > implementation of backend support for rte_flow). > > Here, we create an opt-in flag passed to the command line to allow > this access. We need to do this before ever accessing the database, > because we want to drop all privileges asap, and cannot wait for > a connection to the database to be established and functional before > dropping. There may be distribution specific ways to do capability > management as well (using for example, systemd), but they are not > as universal to the vswitchd as a flag. > > Signed-off-by: Aaron Conole <[email protected]>
Hi Aaron, I briefly tested the injection of a basic RTE flow rule (see my control plane protection patch here for more details[1]). With a non-root user, there are no permission issues that I can see. I have tested with both the i40e (X710) and mlx5 (ConnectX-5 Ex) drivers. Maybe CAP_SYS_RAWIO is only required for more advanced flows but I am surprised that I didn't encounter the issue for neither a vfio-pci based driver nor with a bifurcated driver. [1]: http://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/ _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
