@yuguorui96 先介绍一篇 gp0 的文章： https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
其中一种 get root shell 的方式，是通过完全控制的 wifi SoC 使用 DMA 来完成攻击的，这个 wifi SoC 没有与 IOMMU 形成绑定，作者没有深究根本原因是主 SoC （骁龙 810 ）没有硬件 IOMMU 还是当时的安卓系统没有默认启用 IOMMU ，又提到在该 wifi SoC 的 documentation 中，没有关于 iommu 的 dtbinding 相关的介绍；
查了下骁龙 810 ，其实是有 IOMMU 的，再结合设备树没有做 binding ，我就想当然的认为系统可能是支持 IOMMU 的，但是这个 DMA 设备由于缺少与 IOMMU 的绑定，而没有受到 IOMMU 的保护，这点逻辑在 kernel 中 dma api 的具体实现中也有体现，针对绑定了 iommu 的设备，会走一个 iommu 相关的 dma 分支，没有绑定则会走另一个分支。
因此我会去确认一下，这个案例中的系统版本究竟是否支持 IOMMU 。

@yuguorui96 也就是说，在 IOMMU 被配置的 OS 上，普通的 DMA 请求会被禁止，只有使用 IOMMU 的 DMA 设备能够发起 DMA 访问是吗？非常感谢，会去读一下启动时关于 IOMMU 的配置代码以及阅读一下这篇文章的。

@yuguorui96 谢谢你的回复！现阶段的想法也就只是看看 dma api 了...另外还想再探讨一下关于恶意设备的问题；
由这个恶意设备的例子展开去，现阶段对于类似的 DMA attack 的防护大多基于 IOMMU 机制，而一个设备与 IOMMU 进行绑定，即“使用 IOMMU”来限制 DMA 攻击的情景，kernel boot time 是在板上设备在与驱动进行绑定的 probe 阶段，为设备分配置 IOMMU 。据此我产生的理解就是，一个设备想接上 IOMMU 需要经过驱动绑定的 probe 阶段（？不一定对，源码是： https://elixir.bootlin.com/linux/v5.17.6/source/drivers/base/dd.c#L871 ）
再说回你的例子，如果你说的恶意设备是一个热插拔的具有 DMA 能力的非板上的外部设备，成功挂载且无法匹配任何总线上的驱动，此时程序流不会走到 probe 分支，是否也就意味着该设备不会受到 IOMMU 的保护呢？