"Robin Jarry" <[email protected]> writes:

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

Thanks for taking a look.  You're saying that you tested without this
patch applied, yes?  That could be.  I only know of one hardware which
requires CAP_SYS_RAWIO for rte_flow to function.

> 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]/

I'm surprised as well.  Maybe someone from Mellanox can comment?

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to