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  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:	Sun, 30 May 2010 16:13:59 +0300
From:	Avi Kivity <>
To:	"Michael S. Tsirkin" <>
CC:	Tom Lyon <>,,,,,,,,
Subject: Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers

On 05/30/2010 04:03 PM, Michael S. Tsirkin wrote:
>>>>> IMO this was because this driver does two things: programming iommu and
>>>>> handling interrupts. uio does interrupt handling.
>>>>> We could have moved iommu / DMA programming to
>>>>> a separate driver, and have uio work with it.
>>>>> This would solve limitation of the current driver
>>>>> that is needs an iommu domain per device.
>>>> How do we enforce security then?  We need to ensure that unprivileged
>>>> users can only use the device with an iommu.
>>> Force assigning to iommu before we allow any other operation?
>> That means the driver must be aware of the iommu.
> The userspace driver? Yes. And It is a good thing to be explicit
> there anyway, since this lets userspace map a non-contigious
> virtual address list into a contiguous bus address range.

No, the kernel driver.  It cannot allow userspace to enable bus 
mastering unless it knows the iommu is enabled for the device and remaps 
dma to user pages.

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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists