linux-kernel - Re: [PATCH V2] VFIO driver: Non-privileged user level PCI drivers

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]

Date:	Wed, 30 Jun 2010 08:00:26 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Tom Lyon <pugs@...co.com>, randy.dunlap@...cle.com,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	chrisw@...s-sol.org, joro@...tes.org, hjk@...utronix.de,
	avi@...hat.com, gregkh@...e.de, aafabbri@...co.com,
	scofeldm@...co.com
Subject: Re: [PATCH V2] VFIO driver: Non-privileged user level PCI drivers

On Wed, 2010-06-30 at 16:36 +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 30, 2010 at 12:14:12AM -0600, Alex Williamson wrote:
> > On Tue, 2010-06-08 at 14:21 -0700, Tom Lyon wrote:
> > > The VFIO "driver" is used to allow privileged AND non-privileged processes to 
> > > implement user-level device drivers for any well-behaved PCI, PCI-X, and PCIe
> > > devices.
> > 
> > Hi Tom,
> > 
> > I found a few bugs.  Patch below.  The first chunk clears the
> > pci_config_map on close, otherwise we end up passing virtualized state
> > from one user to the next.  The second is an off by one in the basic
> > perms.  Finally, vfio_bar_fixup() needs an overhaul.  It wasn't setting
> > the lower bits right and is allowing virtual writes of bits that aren't
> > aligned to the size.  This section probably needs another pass or two of
> > refinement.  Thanks,
> > 
> > Alex
> > 
> 
> I still don't see why are we sticking all this emulation in kernel.  It
> is far from performance hotpath and can easily be emulated in userspace.
> qemu does this, you can lift code from there if you like.
> Maybe we need to protect the BARs from being manipulated by userspace,
> but that should be all. No need for tables.

The benefit I see so far is that it removes duplicate code.  Should
every user of this interface try to extract qemu's PCI config space
emulation and jury rig it into their code base?  Tom is already
providing access to more capability bits than the kvm device assignment
code.  If the kernel community will accept it, I think it saves vfio
usperspace writers some hassle and provides a better environment by
having emulation in a single, well tested, hopefully well used place.
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/