Dear Community, Following up on my recent submission regarding the BaseTools security patches (GHSA-w2ff-j9q5-jr6p), I am writing to flag a potential architectural gap I observed during a static analysis of the PciHostBridgeDxe driver and related IOMMU initialization logic (specifically regarding VT-d / AMD-Vi table generation). The Context: While the ecosystem is maturing around USB4/Thunderbolt, we are seeing an increasing number of endpoints requiring massive MMIO resources (e.g., discrete accelerators with 64GB+ BARs) being attached via PCIe tunneling. The Theoretical Logic Flaw: My concern lies in how the current firmware enumerates and isolates devices in a deeply daisy-chained, tunneled topology. The current PciHostBridge resource allocator appears to treat these tunneled hierarchies with standard PCI-to-PCI bridge logic. However, based on my reading of the source:
1. ACS Propagation Gap: In a multi-hop USB4 tunnel, if the intermediate virtual bridges do not correctly assert Access Control Services (ACS) capability―or if the firmware fails to configure the P2P Request Redirect bits correctly―there is a risk of unprotected Peer-to-Peer (P2P) DMA. 2. IOMMU Scope Bypass: If a downstream device (Device B) initiates a P2P transaction targeting an upstream device (Device A) or system memory, and the DMAR (DMA Remapping) tables were generated assuming a flatter topology, the transaction might bypass the IOMMU translation. This could theoretically allow a malicious peripheral attached via USB4 to "snoop" VRAM from an upstream device, bypassing OS-level isolation. The "High-BAR" Aggravation: This is particularly concerning with High-BAR devices (like modern GPUs). The firmware seems to prioritize resource padding for these devices but does not appear to enforce strict ATS (Address Translation Services) invalidation scopes for dynamic tunnels. The Question: Has the community verified the P2P routing path for generic USB4 tunnels in EDK2? Specifically, does the current PciHostBridgeDxe implementation guarantee that all tunneled segments are forced into separate IOMMU groups, or are we relying on the OS driver to patch this up (which would be a firmware vulnerability)? I have not yet constructed a physical test rig to verify this exploit, but the code path suggests undefined behavior. I recommend an immediate review of the P2P routing logic for USB4 root ports. Best regards, Zhenyu Liu Security Researcher 来自 Outlook<http://aka.ms/weboutlook> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121740): https://edk2.groups.io/g/devel/message/121740 Mute This Topic: https://groups.io/mt/117085433/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
