On Fri, Apr 20, 2018 at 11:52:47AM +0800, Jason Wang wrote: > > The biggest issue is that you let userspace poke at the > > device which is also allowed by the IOMMU to poke at > > kernel memory (needed for kernel driver to work). > > I don't quite get. The userspace driver could be built on top of VFIO for > sure. So kernel memory were perfectly isolated in this case. VFIO does what it can but it mostly just has the IOMMU to play with. So don't overestimate what it can do - it assumes a high level of spec compliance for protections to work. For example, ATS is enabled by default if device has it, and that treats translated requests are trusted. FLS is assumed to reset the device for when VFIO is unbound from the device. etc. > > > > Yes, maybe if device is not buggy it's all fine, but > > it's better if we do not have to trust the device > > otherwise the security picture becomes more murky. > > > > I suggested attaching a PASID to (some) queues - see my old post "using > > PASIDs to enable a safe variant of direct ring access". > > > > Then using IOMMU with VFIO to limit access through queue to corrent > > ranges of memory. > > Well userspace driver could benefit from this too. And we can even go > further by using nested IO page tables to share IOVA address space between > devices and a VM. > > Thanks Yes I suggested this separately. -- MST
