[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5613E75E.1040002@scylladb.com>
Date: Tue, 6 Oct 2015 18:23:10 +0300
From: Avi Kivity <avi@...lladb.com>
To: "Michael S. Tsirkin" <mst@...hat.com>,
Vlad Zolotarov <vladz@...udius-systems.com>
Cc: 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,
Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support
On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
>> The only "like VFIO" behavior we implement here is binding the MSI-X
>> interrupt notification to eventfd descriptor.
> There will be more if you add some basic memory protections.
>
> Besides, that's not true.
> Your patch queries MSI capability, sets # of vectors.
> You even hinted you want to add BAR mapping down the road.
BAR mapping is already available from sysfs; it is not mandatory.
> VFIO does all of that.
>
Copying vfio maintainer Alex (hi!).
vfio's charter is modern iommu-capable configurations. It is designed to
be secure enough to be usable by an unprivileged user.
For performance and hardware reasons, many dpdk deployments use
uio_pci_generic. They are willing to trade off the security provided by
vfio for the performance and deployment flexibility of pci_uio_generic.
Forcing these features into vfio will compromise its security and
needlessly complicate its code (I guess it can be done with a "null"
iommu, but then vfio will have to decide whether it is secure or not).
>> This doesn't justifies the
>> hassle of implementing IOMMU-less VFIO mode.
> This applies to both VFIO and UIO really. I'm not sure the hassle of
> maintaining this functionality in tree is justified. It remains to be
> seen whether there are any users that won't taint the kernel.
> Apparently not in the current form of the patch, but who knows.
It is not msix that taints the kernel, it's uio_pci_generic. Msix is a
tiny feature addition that doesn't change the security situation one bit.
btw, currently you can map BARs and dd to /dev/mem to your heart's
content without tainting the kernel. I don't see how you can claim that
msix support makes the situation worse, when root can access every bit
of physical memory, either directly or via DMA.
--
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