From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932622AbbJPRMm (ORCPT ); Fri, 16 Oct 2015 13:12:42 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:34432 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbbJPRMl (ORCPT ); Fri, 16 Oct 2015 13:12:41 -0400 From: Thomas Monjalon To: "Michael S. Tsirkin" , linux-kernel@vger.kernel.org Cc: dev@dpdk.org, Avi Kivity , Stephen Hemminger , hjk@hansjkoch.de, gregkh@linux-foundation.org, Vlad Zolotarov Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X Date: Fri, 16 Oct 2015 19:11:35 +0200 Message-ID: <2696552.dQRxzH79dc@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <5613BB7D.3060202@scylladb.com> References: <1443652138-31782-1-git-send-email-stephen@networkplumber.org> <20151006083356.3da3defa@uryu.home.lan> <5613BB7D.3060202@scylladb.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.