From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752285AbbJFMQE (ORCPT ); Tue, 6 Oct 2015 08:16:04 -0400 Received: from mail-lb0-f177.google.com ([209.85.217.177]:35873 "EHLO mail-lb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751432AbbJFMQC (ORCPT ); Tue, 6 Oct 2015 08:16:02 -0400 Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X To: Stephen Hemminger , "Michael S. Tsirkin" 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> Cc: dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org, linux-kernel@vger.kernel.org From: Avi Kivity Message-ID: <5613BB7D.3060202@scylladb.com> Date: Tue, 6 Oct 2015 15:15:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151006083356.3da3defa@uryu.home.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.