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
| ||
|
Message-ID: <56154AB4.1050509@scylladb.com> Date: Wed, 7 Oct 2015 19:39:16 +0300 From: Avi Kivity <avi@...lladb.com> To: Alex Williamson <alex.williamson@...hat.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 10/07/2015 07:31 PM, Alex Williamson wrote: >>> I >>> guess the no-iommu map would error if the IOVA isn't simply the bus >>> address of the page mapped. >>> >>> Of course this is entirely unsafe and this no-iommu driver should taint >>> the kernel, but it at least standardizes on one userspace API and you're >>> already doing completely unsafe things with uio. vfio should be >>> enlightened at least to the point that it allows only privileged users >>> access to devices under such a (lack of) iommu. >> There is an additional complication. With an iommu, userspace programs >> the device with virtual addresses, but without it, they have to program >> physical addresses. So vfio would need to communicate this bit of >> information. >> >> We can go further and define a better translation API than the current >> one (reading /proc/pagemap). But it's going to be a bigger change to >> vfio than I thought at first. > It sounds like a separate vfio iommu backend from type1, one that just > pins the page and returns the bus address. The curse and benefit would > be that existing type1 users wouldn't "just work" in an insecure mode, > the DMA mapping code would need to be aware of the difference. Still, I > do really prefer to keep vfio as only exposing a secure, iommu protected > device to the user because surely someone will try and users would > expect that removing iommu restrictions from vfio means they can do > device assignment to VMs w/o an iommu. That's what I thought as well, but apparently adding msix support to the already insecure uio drivers is even worse. -- 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