[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151008041913.GB13818@scylladb.com>
Date: Thu, 8 Oct 2015 07:19:13 +0300
From: Gleb Natapov <gleb@...lladb.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Avi Kivity <avi@...lladb.com>,
Alex Williamson <alex.williamson@...hat.com>,
Vlad Zolotarov <vladz@...udius-systems.com>,
Greg KH <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, hjk@...sjkoch.de, corbet@....net,
bruce.richardson@...el.com, avi@...udius-systems.com,
gleb@...udius-systems.com, stephen@...workplumber.org,
alexander.duyck@...il.com
Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists