On 2/21/25 21:04, Jason Gunthorpe wrote:
On Fri, Feb 21, 2025 at 04:28:50AM +0000, Tian, Kevin wrote:
With PASID support, multiple domains can be attached to the device, and
each domain may have different ATS requirements. Therefore, we cannot
simply determine the ATS status in the RID domain attach/detach paths. A
better solution is to use the reference count, as mentioned above.
Okay, that helps connect the dots and makes sense to me. Thanks!
I also have this general feeling that using ATS or not should be some
user policy (ie with sysfs or something) not just always automatic..
Agreed. ATS is inherently insecure because it allows a device to
directly access system memory using translated requests. A malicious
device could exploit this to compromise the system. Currently, Linux
prevents ATS from being enabled on devices with pci_dev->untrusted set.
But this seems insufficient, as only devices connected to external-
facing ports are currently marked as untrusted. It would be preferable
to allow the user to determine which devices are trusted and, therefore,
permitted to use ATS.
Some IOMMU architectures have introduced new features to enhance the
security of ATS, such as the host permission table in VT-d v5.0. This
could be an interesting topic when considering its implementation in the
Linux kernel.
Right now on our devices there is a firmware config that hides the ATS
support from PCI config space and the general guidance is to only turn
it on in very specific situations.
Thanks,
baolu
