On Thu, May 29, 2025 at 01:29:23PM -0300, Jason Gunthorpe wrote: > On Thu, May 29, 2025 at 10:41:15PM +0800, Xu Yilun wrote: > > > > On AMD, the host can "revoke" at any time, at worst it'll see RMP > > > events from IOMMU. Thanks, > > > > Is the RMP event firstly detected by host or guest? If by host, > > host could fool guest by just suppress the event. Guest thought the > > DMA writting is successful but it is not and may cause security issue. > > Is that in scope of the threat model though? Host must not be able to > change DMAs or target them to different memory, but the host can stop > DMA and loose it, surely?
This is within the threat model, this is a data integrity issue, not a DoS issue. If secure firmware don't care, then no component within the TCB could be aware of the data loss. > > Host controls the PCI memory enable bit, doesn't it? That's why DSM should fallback the device to CONFIG_UNLOCKED when memory enable is toggled, that makes TD/TDI aware of the problem. But for IOMMU PT blocking, DSM cannot be aware, TSM must do something. Zhi helps find something in SEV-TIO Firmware Interface SPEC, Section 2.11 which seems to indicate SEV does do something for this. "If a bound TDI sends a request to the root complex, and the IOMMU detects a fault caused by host configuration, the root complex fences the ASID from all further I/O to or from that guest. A host fault is either a host page table fault or an RMP check violation. ASID fencing means that the IOMMU blocks all further I/O from the root complex to the guest that the TDI was bound, and the root complex blocks all MMIO accesses by the guest. When a guest writes to MMIO, the write is silently dropped. When a guest reads from MMIO, the guest reads 1s." Blocking all TDIs should definitely be avoided. Now I'm more sure Unbind before DMABUF revoke is necessary. Thanks, Yilun > > Jason
