On Thu, Nov 7, 2019 at 4:03 AM Alex Williamson <alex.william...@redhat.com> wrote: > > On Thu, 31 Oct 2019 18:03:53 +0100 > Thomas Monjalon <tho...@monjalon.net> wrote: > > > We don't get enough attention on this topic. > > Let me rephrase the issue and the proposals with more people Cc'ed. > > > > We are talking about SR-IOV VFs in VMs > > with a PF managed on the host by DPDK. > > The PF driver is either a (1) bifurcated (Mellanox case), > > or (2) bound to UIO with igb_uio, or (3) bound to VFIO. > > > > In case 1, the PF is still managed by a kernel driver, so no issue. > > > > In case 2, the PF is managed by UIO. > > There is no SR-IOV support in upstream UIO, > > but the out-of-tree module igb_uio works. > > However we would like to drop this legacy module from DPDK. > > Some (most) Linux distributions do not package igb_uio anyway. > > The other issue is that igb_uio is using physical addressing, > > which is not acceptable with OCTEON TX2 for performance reason. > > > > In case 3, the PF is managed by VFIO. This is the case we want to fix. > > VFIO does not allow to create VFs. > > The workaround is to create VFs before binding the PF to VFIO. > > But since Linux 4.19, VFIO forbids any SR-IOV VF management. > > There is a security concern about allowing userspace to manage SR-IOV > > VF messages and taking the responsibility for VFs in the guest. > > > > It is desired to allow the system admin deciding the security levels, > > by adding a flag in VFIO "let me manage VFs, I know what I am doing". > > Reference of "recent" discussion: https://lkml.org/lkml/2018/3/6/855 > > For now, there is no upstream solution merged. > > > > This patch is proposing a solution using an out-of-tree module. > > In this case, the admin will decide explicitly to bind the PF to vfio_pf. > > Unfortunately this solution won't work in environments which > > forbid any out-of-tree module. > > Another concern is that it looks like DPDK-only solution. > > > > We have an issue but we do not want to propose a half-solution > > which would harm other projects and users. > > So the question is: > > Do we accept this patch as a temporary solution? > > Or can we get an agreement soon for an upstream kernel solution? > > > > Thanks for reading and giving your (clear) opinion.
Thanks, Alex for the feedback. > I'm pretty appalled that anyone would consider shipping this module and > actually claiming that it's supported in some way. Seriously, it's Actually DPDK already shipping with this hack using the igb_uio module for UIO. https://git.dpdk.org/dpdk/tree/kernel/linux/igb_uio/igb_uio.c#n44. > disturbing to see a driver that intentionally circumvents a security > issue that we all seem to agree exists, but just hand wave that it > doesn't apply to dpdk configurations. Yes. There is a security issue wrt netdev VFs. That's the reason, I was scared to submit any patch in upstream on this front. Having said that, OVS-DPDK kind of userland programs would like to define the fate of the netdev VF packets of the guest as it is vswitch application. So there is a perception change in who is controlling the who. > Ideas have been suggested > upstream for for quarantining VFs generated from user owned PFs such > that we require an opt-in to make use of them in this way. Nobody > seems to be pursuing such ideas upstream. I don't even see upstream > proposals to add a scary sounding module option to vfio-pci that would > taint the kernel, but make this available. If nothing else, please > remove the vfio name from this abomination, it has nothing to do with > vfio other than to try to subvert the security and isolation that vfio > attempts to provide. Thanks for the feedback. Let's hold on accepting this patch. We would like to have an upstream solution so that DPDK needs to only focus on userspace. I will work on submitting a patch for the discussion in Linux upstream. Let see how the discussion goes, Based on the that, We can revisit fate of this module. > Alex >
