Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Doug,

On 2021-06-22 00:52, Douglas Anderson wrote:

This patch attempts to put forward a proposal for enabling non-strict
DMA on a device-by-device basis. The patch series requests non-strict
DMA for the Qualcomm SDHCI controller as a first device to enable,
getting a nice bump in performance with what's believed to be a very
small drop in security / safety (see the patch for the full argument).

As part of this patch series I am end up slightly cleaning up some of
the interactions between the PCI subsystem and the IOMMU subsystem but
I don't go all the way to fully remove all the tentacles. Specifically
this patch series only concerns itself with a single aspect: strict
vs. non-strict mode for the IOMMU. I'm hoping that this will be easier
to talk about / reason about for more subsystems compared to overall
deciding what it means for a device to be "external" or "untrusted".

If something like this patch series ends up being landable, it will
undoubtedly need coordination between many maintainers to land. I
believe it's fully bisectable but later patches in the series
definitely depend on earlier ones. Sorry for the long CC list. :(

Unfortunately, this doesn't work. In normal operation, the default domains should be established long before individual drivers are even loaded (if they are modules), let alone anywhere near probing. The fact that iommu_probe_device() sometimes gets called far too late off the back of driver probe is an unfortunate artefact of the original probe-deferral scheme, and causes other problems like potentially malformed groups - I've been forming a plan to fix that for a while now, so I for one really can't condone anything trying to rely on it. Non-deterministic behaviour based on driver probe order for multi-device groups is part of the existing problem, and your proposal seems equally vulnerable to that too.

FWIW we already have a go-faster knob for people who want to tweak the security/performance compromise for specific devices, namely the sysfs interface for changing a group's domain type before binding the relevant driver(s). Is that something you could use in your application, say from an initramfs script?

Thanks,
Robin.

Douglas Anderson (6):
   drivers: base: Add the concept of "pre_probe" to drivers
   drivers: base: Add bits to struct device to control iommu strictness
   PCI: Indicate that we want to force strict DMA for untrusted devices
   iommu: Combine device strictness requests with the global default
   iommu: Stop reaching into PCIe devices to decide strict vs. non-strict
   mmc: sdhci-msm: Request non-strict IOMMU mode

  drivers/base/dd.c             | 10 +++++--
  drivers/iommu/dma-iommu.c     |  2 +-
  drivers/iommu/iommu.c         | 56 +++++++++++++++++++++++++++--------
  drivers/mmc/host/sdhci-msm.c  |  8 +++++
  drivers/pci/probe.c           |  4 ++-
  include/linux/device.h        | 11 +++++++
  include/linux/device/driver.h |  9 ++++++
  include/linux/iommu.h         |  2 ++
  8 files changed, 85 insertions(+), 17 deletions(-)




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux