linux-kernel - Re: [PATCH] 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]

Message-ID: <20100601095532.GA9178@redhat.com>
Date:	Tue, 1 Jun 2010 12:55:32 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Tom Lyon <pugs@...co.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, chrisw@...s-sol.org, joro@...tes.org,
	hjk@...utronix.de, gregkh@...e.de, aafabbri@...co.com,
	scofeldm@...co.com
Subject: Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers

On Tue, Jun 01, 2010 at 11:10:45AM +0300, Avi Kivity wrote:
> On 05/31/2010 08:10 PM, Michael S. Tsirkin wrote:
>> On Mon, May 31, 2010 at 02:50:29PM +0300, Avi Kivity wrote:
>>    
>>> On 05/30/2010 05:53 PM, Michael S. Tsirkin wrote:
>>>      
>>>> So what I suggested is failing any kind of access until iommu
>>>> is assigned.
>>>>
>>>>        
>>> So, the kernel driver must be aware of the iommu.  In which case it may
>>> as well program it.
>>>      
>> It's a kernel driver anyway. Point is that
>> the *device* driver is better off not programming iommu,
>> this way we do not need to reprogram it for each device.
>>    
>
> The device driver is in userspace.

I mean the kernel driver that grants userspace the access.

>  It can't program the iommu.
> What  
> the patch proposes is that userspace tells vfio about the needed  
> mappings, and vfio programs the iommu.

There seems to be some misunderstanding.  The userspace interface
proposed forces a separate domain per device and forces userspace to
repeat iommu programming for each device.  We are better off sharing a
domain between devices and programming the iommu once.

The natural way to do this is to have an iommu driver for programming
iommu.

This likely means we will have to pass the domain to 'vfio' or uio or
whatever the driver that gives userspace the access to device is called,
but this is only for security, there's no need to support programming
iommu there.

And using this design means the uio framework changes
required would be minor, so we won't have to duplicate code.

> -- 
> error compiling committee.c: too many arguments to function
--
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/