linux-kernel - Re: [RFC PATCH 3/3] kvm: Add VFIO device for handling IOMMU cache coherency

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130930132302.GC11993@redhat.com>
Date:	Mon, 30 Sep 2013 16:23:02 +0300
From:	Gleb Natapov <gleb@...hat.com>
To:	Alex Williamson <alex.williamson@...hat.com>
Cc:	kvm@...r.kernel.org, aik@...abs.ru, benh@...nel.crashing.org,
	bsd@...hat.com, linux-kernel@...r.kernel.org, mst@...hat.com
Subject: Re: [RFC PATCH 3/3] kvm: Add VFIO device for handling IOMMU cache
 coherency

On Sun, Sep 29, 2013 at 09:55:59AM -0600, Alex Williamson wrote:
> On Sun, 2013-09-29 at 17:44 +0300, Gleb Natapov wrote:
> > On Sun, Sep 29, 2013 at 07:52:28AM -0600, Alex Williamson wrote:
> > > On Sun, 2013-09-29 at 16:16 +0300, Gleb Natapov wrote:
> > > > On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> > > > > So far we've succeeded at making KVM and VFIO mostly unaware of each
> > > > > other, but there's any important point where that breaks down.  Intel
> > > > > VT-d hardware may or may not support snoop control.  When snoop
> > > > > control is available, intel-iommu promotes No-Snoop transactions on
> > > > > PCIe to be cache coherent.  That allows KVM to handle things like the
> > > > > x86 WBINVD opcode as a nop.  When the hardware does not support this,
> > > > > KVM must implement a hardware visible WBINVD for the guest.
> > > > > 
> > > > > We could simply let userspace tell KVM how to handle WBINVD, but it's
> > > > > privileged for a reason.  Allowing an arbitrary user to enable
> > > > > physical WBINVD gives them a more access to the hardware.  Previously,
> > > > > this has only been enabled for guests supporting legacy PCI device
> > > > > assignment.  In such cases it's necessary for proper guest execution.
> > > > > We therefore create a new KVM-VFIO virtual device.  The user can add
> > > > > and remove VFIO groups to this device via file descriptors.  KVM
> > > > > makes use of the VFIO external user interface to validate that the
> > > > > user has access to physical hardware and gets the coherency state of
> > > > > the IOMMU from VFIO.  This provides equivalent functionality to
> > > > > legacy KVM assignment, while keeping (nearly) all the bits isolated.
> > > > > 
> > > > Looks good overall to me, one things though: to use legacy device
> > > > assignment one needs root permission, so only root user can enable
> > > > WBINVD emulation.
> > > 
> > > That's not entirely accurate, legacy device assignment can be used by a
> > > non-root user, libvirt does this all the time.  The part that requires
> > > root access is opening the pci-sysfs config file, the rest can be
> > > managed via file permissions on the remaining sysfs files.
> > > 
> > So how libvirt manages to do that as non-root user if pci-sysfs config
> > file needs root permission. I didn't mean to say that legacy code
> > checks for root explicitly, what I meant is that at some point root
> > permission is needed.
> 
> Yes, libvirt needs admin permission for legacy to bind to pci-stub,
> change permission on sysfs files and pass an opened pci config sysfs
> file descriptor.  For vfio libvirt needs admin permission to bind to
> vfio-pci and change group file permission.  From that perspective the
> admin requirement is similar.
> 
Yes, certainly appears so. Thanks.

--
			Gleb.
--
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/