From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@scylladb.com>
Subject: Re: [PATCH 2/2] uio: new driver to support PCI MSI-X
Date: Tue, 6 Oct 2015 15:15:57 +0300
Message-ID: <5613BB7D.3060202@scylladb.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>
 <CAOYyTHZHdS4Hr7Qq5FOdDMtooAKiAb26efAJ=NaxyMVqkYqiHQ@mail.gmail.com>
 <20151006013000-mutt-send-email-mst@redhat.com>
 <20151006083356.3da3defa@uryu.home.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org,
 linux-kernel@vger.kernel.org
To: Stephen Hemminger <stephen@networkplumber.org>,
 "Michael S. Tsirkin" <mst@redhat.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com
 [209.85.215.52]) by dpdk.org (Postfix) with ESMTP id C02173787
 for <dev@dpdk.org>; Tue,  6 Oct 2015 14:16:00 +0200 (CEST)
Received: by lafb9 with SMTP id b9so54432337laf.0
 for <dev@dpdk.org>; Tue, 06 Oct 2015 05:16:00 -0700 (PDT)
In-Reply-To: <20151006083356.3da3defa@uryu.home.lan>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.
>
> 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. 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.

vfio's charter was explicitly aiming for modern setups with iommus.

This could be revisited, but I agree it will have even more resistance, 
justified IMO.

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.