On 09/30/15 13:58, Michael S. Tsirkin wrote: > On Wed, Sep 30, 2015 at 01:37:22PM +0300, Vlad Zolotarov wrote: >> >> On 09/30/15 00:49, Michael S. Tsirkin wrote: >>> On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wrote: >>>> On Tue, 29 Sep 2015 23:54:54 +0300 >>>> "Michael S. Tsirkin" <mst at redhat.com> wrote: >>>> >>>>> On Tue, Sep 29, 2015 at 07:41:09PM +0300, Vlad Zolotarov wrote: >>>>>> The security breach motivation u brought in "[RFC PATCH] uio: >>>>>> uio_pci_generic: Add support for MSI interrupts" thread seems a bit weak >>>>>> since one u let the userland access to the bar it may do any funny thing >>>>>> using the DMA engine of the device. This kind of stuff should be >>>>>> prevented >>>>>> using the iommu and if it's enabled then any funny tricks using MSI/MSI-X >>>>>> configuration will be prevented too. >>>>>> >>>>>> I'm about to send the patch to main Linux mailing list. Let's continue >>>>>> this >>>>>> discussion there. >>>>> Basically UIO shouldn't be used with devices capable of DMA. >>>>> Use VFIO for that (yes, this implies an emulated or PV IOMMU). >> If there is an IOMMU in the picture there shouldn't be any problem to use >> UIO with DMA capable devices. > UIO doesn't enforce the IOMMU though. That's why it's not a good fit.
Having said all that - does UIO denies to work with the devices with DMA capability today? Either i have missed that logic or it's not there. So all what u are so worried about may already be done today. That's why I don't understand why adding a support for MSI/MSI-X interrupts would change anything here. U are right that UIO *today* has a security hole however it should be addressed separately and the same solution that will cover the the security breach in the current code will cover the "MSI/MSI-X security vulnerability" because they are actually exactly the same issue. > >>>>> I don't think this can change. >>>> Given there is no PV IOMMU and even if there was it would be too slow for >>>> DPDK >>>> use, I can't accept that. >>> QEMU does allow emulating an iommu. >> Amazon's EC2 xen HV doesn't. At least today. Therefore VFIO is not an option >> there. > Not only that, a bunch of boxes have their IOMMU disabled. > So for such systems, you can't have userspace poking at > device registers. You need a kernel driver to validate > userspace requests before passing them on to devices. I think u are describing a HV functionality here. ;) And yes, u are absolutely right, HV has to control the non-privileged userland. For HV/non-virtualized boxes a possible solution could be to allow UIO only for some privileged group of processes. > >> And again, it's a general issue not DPDK specific. >> Today one has to develop some proprietary modules (like igb_uio) to >> workaround the issue and this is lame. > Of course it is lame. So don't bypass the kernel then, use the upstream > drivers. This would impose a heavy performance penalty. The whole idea is to bypass kernel. Especially for networking... > >> IMHO uio_pci_generic should >> be fixed to be able to properly work within any virtualized environment and >> not only with KVM. > The motivation for UIO is pretty clear: > > For many types of devices, creating a Linux kernel driver is > overkill. All that is really needed is some way to handle an > interrupt and provide access to the memory space of the > device. The logic of controlling the device does not > necessarily have to be within the kernel, as the device does > not need to take advantage of any of other resources that the > kernel provides. One such common class of devices that are > like this are for industrial I/O cards. > > Devices doing DMA do need to take advantage of memory protection > that the kernel provides. Well, yeah - but who said I has to be forbidden to work with the device if MSI-X interrupts is my only option? Kernel may provide a protection in the way that it would check the process permissions and deny the UIO access to non-privileged processes. I'm not sure it's the case today and if it's not the case then, as mentioned above, this would rather be fixed ASAP exactly due to reasons u bring up here. And once it's done there shouldn't be any limitation to allow MSI or MSI-X interrupts along with INT#X. > >>> DPDK uses static mappings, so I >>> doubt it's speed matters at all. >>> >>> Anyway, DPDK is doing polling all the time. I don't see why does it >>> insist on using interrupts to detect link up events. Just poll for that >>> too. >>>
