To sum it up, We want to remove the need of the out-of-tree module igb_uio. 3 possible implementations were discussed so far: - new UIO driver - extend uio_pci_generic - VFIO without IOMMU
It is preferred to avoid creating yet another module to support. That's why the uio_pci_generic extension would be nice. In my understanding, there are currently 2 issues with the patches from Vlad and Stephen: - IRQ must be mapped to a fd without using a new ioctl - MSI-X handling in userspace breaks the memory protection I'm confident the first issue can be fixed with something like sysfs. About the "security" concern, mainly expressed by MST, I think the idea of Avi (below) deserves to be discussed. 2015-10-06 15:15, Avi Kivity: > On 10/06/2015 10:33 AM, Stephen Hemminger wrote: > > Other than implementation objections, so far the two main arguments > > against this reduce to: > > 1. If you allow UIO ioctl then it opens an API hook for all the crap out > > of tree UIO drivers to do what they want. > > 2. If you allow UIO MSI-X then you are expanding the usage of userspace > > device access in an insecure manner. [...] > btw, (2) doesn't really add any insecurity. The user could already poke > at the msix tables (as well as perform DMA); they just couldn't get a > useful interrupt out of them. > > Maybe a module parameter "allow_insecure_dma" can be added to > uio_pci_generic. Without the parameter, bus mastering and msix is > disabled, with the parameter it is allowed. This requires the sysadmin > to take a positive step in order to make use of their hardware. Giving the control of the memory protection level to the distribution or the administrator looks a good idea. When allowing insecure DMA, a log will make clear how it is supported -or not- by the system provider. >From another thread: 2015-10-01 14:09, Michael S. Tsirkin: > If Linux keeps enabling hacks, no one will bother doing the right thing. > Upstream inclusion is the only carrot Linux has to make people do the > right thing. The "right thing" should be guided by the users needs at a given time. The "carrot" for a better solution will be to have a well protected system.
