From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id B22E3569A for ; Tue, 6 Oct 2015 15:42:28 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id A62E3C1A0BC8; Tue, 6 Oct 2015 13:42:27 +0000 (UTC) Received: from redhat.com (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t96DgNuQ019760; Tue, 6 Oct 2015 09:42:24 -0400 Date: Tue, 6 Oct 2015 16:42:22 +0300 From: "Michael S. Tsirkin" To: Stephen Hemminger Message-ID: <20151006154611-mutt-send-email-mst@redhat.com> References: <1443652138-31782-1-git-send-email-stephen@networkplumber.org> <1443652138-31782-3-git-send-email-stephen@networkplumber.org> <20151001104505-mutt-send-email-mst@redhat.com> <20151005215455.GA7608@redhat.com> <20151006013000-mutt-send-email-mst@redhat.com> <20151006083356.3da3defa@uryu.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151006083356.3da3defa@uryu.home.lan> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org, linux-kernel@vger.kernel.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: Tue, 06 Oct 2015 13:42:29 -0000 On Tue, Oct 06, 2015 at 08:33:56AM +0100, 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. That's not all. Without MSI one can detect insecure usage by detecting userspace enabling bus mastering. This can be detected simply using lspci. Or one can also imagine a configuration where this ability is disabled, is logged, or taints kernel. This seems like something that might be worth having for some locked-down systems. OTOH enabling MSI requires enabling bus mastering so suddenly we have no idea whether device can be/is used in a safe way. > > Another alternative which I explored was making a version of VFIO that > works without IOMMU. It solves #1 but actually increases the likely negative > response to arguent #2. No - because VFIO has limited protection against device misuse by userspace, by limiting access to sub-ranges of device BARs and config space. For a device that doesn't do DMA, that will be enough to make it secure to use. That's a pretty weak excuse to support userspace drivers for PCI devices without an IOMMU, but it's the best I heard so far. Is that worth the security trade-off? I'm still not sure. > This would keep same API, and avoid having to > modify UIO. But we would still have the same (if not more resistance) > from IOMMU developers who believe all systems have to be secure against > root. "Secure against root" is a confusing way to put it IMHO. We are talking about memory protection. So that's not IOMMU developers IIUC. I believe most kernel developers will agree it's not a good idea to let userspace corrupt kernel memory. Otherwise, the driver can't be supported, and maintaining upstream drivers that can't be supported serves no useful purpose. Anyone can load out of tree ones just as well. VFIO already supports MSI so VFIO developers already have a lot of experience with these issues. Getting their input would be valuable. -- MST