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 PHC | |
Open Source and information security mailing list archives
| ||
|
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