Re: [PATCH v3 02/10] iommu/sva: Bind process address spaces to devices

[Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]

On Mon, 24 Sep 2018 13:07:47 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:

> On 23/09/2018 04:05, Lu Baolu wrote:
> > Hi,
> > 
> > On 09/21/2018 01:00 AM, Jean-Philippe Brucker wrote:  
> >> Add bind() and unbind() operations to the IOMMU API. Bind()
> >> returns a PASID that drivers can program in hardware, to let their
> >> devices access an mm. This patch only adds skeletons for the
> >> device driver API, most of the implementation is still missing.  
> > 
> > Is it possible that a malicious process can unbind a pasid which is
> > used by another normal process?  
> 
> Yes, it's up to the device driver that calls unbind() to check that
> the caller is allowed to unbind this PASID. We can't do it ourselves
> since unbind() could also be called from a kernel thread for example
> from a cleanup function in some workqueue, outside the context of the
> process to unbind.
> 
I am wondering if we can avoid the complexity around permission
checking by simply _only_ allow bind/unbind() on current mm? what would
be the missing use cases if we bind current only?
It can also avoid other race such as unbind and mmu_notifier release
call.

> Jean
> 
> > 
> > It might happen in below sequence:
> > 
> > 
> > Process A                       Process B
> > =========                       =========
> > iommu_sva_init_device(dev)
> > iommu_sva_bind_device(dev)
> > ....
> > device access mm of A with
> > #PASID returned above
> > ....
> >                                 iommu_sva_unbind_device(dev, #PASID)
> > ....
> > [unrecoverable errors]
> > 
> > I didn't have a thorough consideration of this. Sorry if this has
> > been prevented.
> > 
> > Best regards,
> > Lu Baolu  

[Jacob Pan]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu