> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker@xxxxxxx] > Sent: Thursday, September 27, 2018 11:06 PM > > On 26/09/2018 19:01, Jacob Pan wrote: > > On Mon, 24 Sep 2018 13:07:47 +0100 > > Jean-Philippe Brucker <jean-philippe.brucker@xxxxxxx> 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. > > Actually I'm not too concerned about a process unbinding another one, > since in general only the kernel will hold the PASID values. Userspace > shouldn't even need to see them, so issuing unbind() with the wrong > PASID isn't an easy mistake. > well, it depends on which scenario is talked here. for native SVA with device driver in kernel, your description is correct. for native SVA with device driver in user space, then user space needs to see/hold PASIDs and program them to device specific register. for virtual SVA (vtd case), Qemu needs to see/hold PASIDs and pass to guest upon any PASID allocation request thru a PV channel, as you just saw in another thread. :-) Thanks Kevin
