A Thunderbolt / USB4 port exposes raw PCIe, and PCIe devices can issue Direct Memory Access (DMA) — reads and writes straight to physical RAM, bypassing the CPU. Without protection, any plugged-in device can address the full physical space:
no IOMMU: device_addr → physical_addr (identity, unchecked)
An IOMMU (Intel VT-d / AMD-Vi) sits between the port and memory and translates every DMA request through a per-device page table, exactly like the CPU's MMU does for processes:
with IOMMU: allowed ⇔ device_addr ∈ [win_start, win_start + win_size)
physical_addr = IOMMU_PageTable[device][device_addr]
else → DMA remapping fault, request dropped in hardware
- IOMMU toggle — with it off, every request reaches memory (the pre-2020 default on many laptops; this is exactly the class of bug behind the Thunderclap and BitLocker cold-boot-adjacent DMA attacks).
- Device: Trusted / Malicious — a trusted peripheral only ever touches its own assigned buffer; a malicious or firmware-compromised one scans arbitrary physical addresses looking for secrets.
- DMA buffer window — how large a region the OS mapped for this device. Even under IOMMU enforcement, a wider window is a wider attack surface for a malicious device landing lucky hits inside it — this is why real drivers request the smallest buffer they need.
- Kernel pages touched — should stay at zero whenever IOMMU is on, because the mapped window is placed away from kernel/secret pages by construction. Watch it climb the moment you switch IOMMU off.
Real-world relevance: Windows' "Kernel DMA Protection" and macOS's Thunderbolt access controls both implement exactly this IOMMU gate by default on modern laptops — this simulation shows why turning it off for "compatibility" reopens a direct hardware path into RAM.