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. I'm pretty appalled that anyone would consider shipping this module and actually claiming that it's supported in some way. Seriously, it's 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. 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, Alex
