From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id 044F38D9B for ; Fri, 16 Oct 2015 19:12:40 +0200 (CEST) Received: by wicll6 with SMTP id ll6so20776070wic.1 for ; Fri, 16 Oct 2015 10:12:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=DRepecPnzQvUg6IHket9rkfHYuFO55fiKzVZ4CZFhRs=; b=asPLgmgCQiwTxufb1DnJkPmMRNzGYzLKiPs05QMgEaKqTpgXX0EGshtGjIu6R98HVm PkfmTzrifnlFAIC3tjC0PGm94kaJFZqCUpeyj0TJL1UNOu8vWF2Y64Xlf7wtttwz0Ci0 oAELLO4CIJdU+tY23KmCDlFYWEIk5pEfGbKg/lsmgnBdFpytbZ0F9vqMiB+K5bEF3/qB vrNIyYX5lM1RZybZB1Eon3+NqINW2GsMobm1hTFumrT2nVu/Mg20/qg5soDAeExcB5a6 l2M8jEWPYBt8IbS/fmD6nPJEOglWjdJSer3n2MCBOg9KiUw9ESJ9swRQtRA5fDA6zgJy JnfQ== X-Gm-Message-State: ALoCoQnNxk5LtYPAkCOcJFYSGIzjezsfSn52aPuxU4o0H3xLkA5TCBeU0dFUH3Ykuw7G4s9pGqOQ X-Received: by 10.194.112.162 with SMTP id ir2mr20045670wjb.40.1445015559756; Fri, 16 Oct 2015 10:12:39 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id r15sm3939825wib.18.2015.10.16.10.12.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2015 10:12:38 -0700 (PDT) From: Thomas Monjalon To: "Michael S. Tsirkin" , linux-kernel@vger.kernel.org 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" Cc: Avi Kivity , dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 17:12:40 -0000 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.