From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751624AbbJHETS (ORCPT ); Thu, 8 Oct 2015 00:19:18 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:37054 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751482AbbJHETQ (ORCPT ); Thu, 8 Oct 2015 00:19:16 -0400 Date: Thu, 8 Oct 2015 07:19:13 +0300 From: Gleb Natapov To: "Michael S. Tsirkin" Cc: Avi Kivity , Alex Williamson , Vlad Zolotarov , Greg KH , linux-kernel@vger.kernel.org, hjk@hansjkoch.de, corbet@lwn.net, bruce.richardson@intel.com, avi@cloudius-systems.com, gleb@cloudius-systems.com, stephen@networkplumber.org, alexander.duyck@gmail.com Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support Message-ID: <20151008041913.GB13818@scylladb.com> References: <56124EDB.3070701@scylladb.com> <20151006143821.GA11541@redhat.com> <5613DE26.1090202@cloudius-systems.com> <20151006174648-mutt-send-email-mst@redhat.com> <5613E75E.1040002@scylladb.com> <1444157480.4059.67.camel@redhat.com> <5614C11B.6090601@scylladb.com> <1444235464.4059.169.camel@redhat.com> <56154AB4.1050509@scylladb.com> <20151007230553-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151007230553-mutt-send-email-mst@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08, 2015 at 12:05:11AM +0300, Michael S. Tsirkin wrote: > On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote: > > That's what I thought as well, but apparently adding msix support to the > > already insecure uio drivers is even worse. > > I'm glad you finally agree what these drivers are doing is insecure. > Michael, please stop this meaningless world play. The above is said in the contexts of a device that is meant to be accessible by regular users and obviously for that purpose uio is insecure (in its current state btw). If you give user access to your root block device this device will be insecure too, so according to your logic block device is insecure? Pushing the code from uio to vfio means that vfio will have to implement access policy by itself - allow iommu mode to regular users, but no-iommu to root only. Implementing policy in the kernel is bad. Well the alternative is to add /dev/vfio/nommu like you've said, but what would be the difference between this and uio eludes me. -- Gleb.