lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1444318288.4059.191.camel@redhat.com>
Date:	Thu, 08 Oct 2015 09:31:28 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	Avi Kivity <avi@...lladb.com>
Cc:	"Michael S. Tsirkin" <mst@...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, 2015-10-08 at 16:20 +0300, Avi Kivity wrote:
> On 10/08/2015 01:26 PM, Michael S. Tsirkin wrote:
> > On Thu, Oct 08, 2015 at 12:19:20PM +0300, Avi Kivity wrote:
> >> We are in the strange situation that the Alex is open to adding an insecure
> >> mode to vfio,
> > I don't find this strange. It seems to make sense. VFIO is
> > already used with DMA capable devices.
> 
> It's strange to me because it's charter was for iommu-protected device 
> assignment, while uio_pci_generic is for generic pci userspace.

To be clear, I'm not necessarily advocating an insecure mode of vfio,
I'm pointing out that vfio is built on the security, isolation, and
services advertised by the iommu layer.  That layer doesn't exist in a
no-iommu system, but a stub iommu driver that disregards the intended
purpose of iommu groups and implements those services could likely fool
vfio into working.  From a code re-use standpoint, there are some clear
advantages to doing that even though it's rather dastardly at the iommu
level.  There's not too much I can do to prevent such a thing, vfio has
to trust someone and in this case it's the core kernel iommu services.
So if such a task was attempted, I'd want to be involved and enlighten
vfio at least to the point where we can make it clear to users which
uses are secure and which are not.  Thanks,

Alex

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ