摘要
USB4 将 Thunderbolt 3 的 PCIe 隧道纳入通用接口标准，使单个 Type-C 端口同时承载 USB 3.2、DisplayPort 和 PCIe 数据流。然而，USB4 规范对 PCIe 隧道的身份认证和访问控制采用了“可选”策略——多数主机控制器默认信任连接的任何设备，将其分配的 PCIe 总线地址直接暴露给外部世界。攻击者可通过恶意 USB4 设备构造 TLP，绕过 IOMMU 的 DMA 重映射，直接读写主机物理内存。
USB4 的 PCIe 隧道
USB4 的协议分层与隧道模型
USB4 基于 Thunderbolt 3 技术，采用分层架构：物理层（PHY）、链路层（Link Layer）、传输层（Transport Layer）和协议适配层（Protocol Adapter）。其核心创新在于隧道化——将 PCIe、DisplayPort 和 USB 3.2 的数据流封装在统一的路由包头中，通过 USB4 路由器（Host Router 与 Device Router）在源与目标之间传输。
USB4 路由器维护路由表，根据包头中的目的地址转发隧道包。主机路由器位于 CPU 侧的 USB4 主控，负责将 PCIe 隧道包解封后注入主机的 PCIe 总线；设备路由器位于外部 USB4 设备（如扩展坞、外置 GPU）中，将设备的 PCIe 请求封装为隧道包发往主机。
以下是数据的打包流向示意：
【外部信号源】 【协议适配层】 【传输层/隧道】 【物理层】
PCIe 信号 ────┐ ┌──────────────┐ ┌────────────────┐ ┌────────────┐
│ │ PCIe适配器 │ │ PCIe隧道 │ │ │
DP 信号 ──────┼─────►│ DP适配器 ├─────►│ DP隧道 ├─────►│ USB4 物理层│
│ │ │ │ │ │ (Type-C) │
USB 3.2信号 ──┘ │ USB3适配器 │ │ USB 3.2隧道 │ │ │
└──────────────┘ └────────────────┘ └────────────┘关键攻击面：USB4 设备路由器与主机路由器之间的隧道建立过程中，主机默认信任设备声明的 PCIe 拓扑（如 BAR 地址、设备 ID）。规范虽定义了可选的基于证书的身份验证机制，但大多数商用 USB4 主控和操作系统并未强制启用——攻击者只需连接一个恶意 USB4 设备，即可在主机 PCIe 总线上注册任意设备。
PCIe 隧道的 TLP 封装
以下是数据包封装的逻辑层级图解与说明：
+-----------------------------------------------------------+
| 原始 PCIe TLP (Header + Data Payload + ECRC) |
+-----------------------------------------------------------+
|
▼ 封装（添加隧道适配层头）
+-----------------------------------------------------------+
| USB4 隧道包负载 (Tunneled Packet Payload) |
| +-------------------------------------------------------+ |
| | PCIe Adapter Header (适配器头，包含序列号/帧信息等) | |
| +-------------------------------------------------------+ |
| | TLP 0 (PCIe原生TLP内容，以 32-bit (DW) 对齐 ) | |
| +-------------------------------------------------------+ |
| | ... | |
| +-------------------------------------------------------+ |
| | TLP n ... | |
| +-------------------------------------------------------+ |
+-----------------------------------------------------------+
|
▼ 封装（添加传输层路由与控制）
+-----------------------------------------------------------+
| USB4 传输层数据包 (Transport Layer Packet) |
| +-------------------------------------------------------+ |
| | Transport Header (USB4 传输层头部：路径ID/包类型等) | |
| +-------------------------------------------------------+ |
| | Packet Payload (即上述的 USB4 隧道包负载) | |
| +-------------------------------------------------------+ |
| | Framing / CRC (USB4 帧尾校验) | |
| +-------------------------------------------------------+ |
+-----------------------------------------------------------+当 USB4 设备发起 PCIe 读/写请求时，其内部 PCIe 控制器生成标准 TLP（事务层数据包），包含请求者 ID（BDF）、目标物理地址、数据载荷和可选的 ECRC。设备路由器将该 TLP 作为有效载荷封装进 USB4 隧道包，添加路由头和隧道类型字段（Protocol_ID = 0x04 表示 PCIe），通过 USB4 链路发送至主机路由器。
主机路由器收到隧道包后，剥离 USB4 包头，提取原始 TLP，然后将其注入主机的 PCIe 根复合体。注入过程对于根复合体来说，与内部 PCIe 端点发起的 TLP 无异——这意味着，如果该 TLP 的目标地址是系统内存（存储器写或读请求），根复合体将直接执行 DMA 操作，而不会区分其来源于内部插槽还是外部 USB4 设备。
IOMMU 在 USB4 隧道下的保护盲区
IOMMU 的标准 DMA 重映射模型
IOMMU 使用设备特定的 DMA 重映射表（Intel VT-d 的 Context Entry 或 AMD-Vi 的 Device Table），将 PCIe 设备的 Requester ID（BDF）映射到 I/O 页表。
当设备发起 DMA 请求时，IOMMU 根据 BDF 查找对应的页表，将设备提供的客户物理地址（GPA）转换为主机物理地址（HPA），并检查访问权限。
对 PCIe 隧道而言，TLP 中的 Requester ID 由 USB4 设备路由器报告给主机路由器，再填入 PCIe 事务层。主机 OS 为这个 Requester ID 建立 IOMMU 映射。 理论上，如果 IOMMU 配置正确，恶意的 USB4 设备只能访问被明确授权的主机物理内存区域。
TLP 注入绕过 IOMMU
问题出现在 IOMMU 映射建立之前或配置疏漏时：
预启动阶段：在 UEFI 固件初始化 USB4 主控和 IOMMU 之前，主机可能已经允许 USB4 设备枚举。此时 IOMMU 尚未启用或映射不完整，设备可以发起携带任意目标物理地址的 TLP，直接读写系统内存。攻击者可在连接设备后快速注入恶意 TLP，在 OS 接管前完成内存篡改。 BIOS/UEFI 的默认直通配置：某些 OEM 的 BIOS 为兼容旧操作系统，可能为 USB4 连接的设备设置 IOMMU 直通（Identity Mapping），即 GPA == HPA，设备可访问任意物理内存。这常见于未正确配置的固件。 利用 USB4 的热插拔事件：攻击者在系统运行中插入恶意设备，主机会执行热插拔流程重新枚举 PCIe 设备，期间 IOMMU 映射可能暂时处于宽松模式或未完全配置。
即使 IOMMU 已正确配置，攻击者仍可尝试通过地址伪造来绕过：构造 TLP 时，不填写恶意目标地址，而是填写一个属于合法映射范围内的 GPA，但通过修改 TLP 的其他字段（如 ECRC 或 payload size）触发内存破坏。然而，更直接的攻击是要求主机固件分配一个巨大的 BAR 空间，利用 BAR 覆盖内核内存区域——此类攻击在 Thunderbolt 3 时代已有先例（Thunderspy）。
权限叠加
PCIe 访问控制服务（ACS）用于在多设备 PCIe 拓扑中强制点对点传输，防止一端点直接访问另一个端点的 DMA 流量。USB4 隧道往往被实现为单个 PCIe 层次，许多 USB4 主控在隧道端点之间不启用 ACS，导致设备 A 可以嗅探或劫持设备 B 的 DMA 事务。在共享集线器的场景下，一个恶意 USB4 设备有可能通过操纵 TLP 路由来访问同伴设备的 IOMMU 映射区域。
恶意 USB4 设备的 TLP 注入 PoC
FPGA 实现一个简化的 USB4 设备路由器逻辑，能够在链路初始化后自动建立 PCIe 隧道，并发送自定义 TLP。
具体步骤：
在 FPGA 中例化 PCIe 端点 IP 核（如 Xilinx PCIe DMA 引擎），配置为默认的设备 ID。 编写 USB4 传输层状态机，完成 USB4 链路训练、时间同步和路由器配置。 实现 PCIe 协议适配层，将本地 PCIe TLP 封装为 USB4 隧道包，加上 Protocol ID 0x04。 构造 TLP 写入物理地址 0x1000（假设为主机内核 BSS 区域），数据为恶意 shellcode。
通过 Linux thunderbolt 驱动注入 TLP
如果无法访问 FPGA，可以使用 Linux 内核的 thunderbolt 子系统，通过 sysfs 接口向连接的 USB4 设备发送隧道控制命令。但直接注入 TLP 需要内核模块支持，以下展示一个简化的概念代码，模拟在主机侧通过 PCIe 字符设备直接发送 TLP 到 USB4 域：
// usb4_tlp_inject.c — 概念验证：通过 /dev/tb 发送恶意 TLP
// 注意：需要启用 CONFIG_USB4_DEBUG 和 root 权限
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <sys/ioctl.h>
// 假设的 USB4 隧道发送 ioctl 命令
#define USB4_XDOM_TX_TLP _IOW('U', 0x10, struct usb4_tlp_pkt)
struct usb4_tlp_pkt {
uint32_t route;
uint32_t adapter;
uint16_t tlp_len;
uint8_t tlp_data[1024];
};
int main() {
int fd = open("/dev/thunderbolt0", O_RDWR);
if (fd < 0) {
perror("open");
return1;
}
// 构造一个存储器写 TLP：目标物理地址 0x1000000，写入 8 字节 0xDEADBEEF
struct usb4_tlp_pkt pkt = {0};
pkt.route = 0; // 到主机路由器
pkt.adapter = 1; // PCIe 隧道适配器
// 简化的 TLP 头（实际需根据 PCIe 规范构造）
uint32_t *tlp = (uint32_t *)pkt.tlp_data;
tlp[0] = 0x40000001; // 32-bit 地址存储器写，长度 1 DW
tlp[1] = 0x01000000; // 目标地址 0x1000000
tlp[2] = 0xDEADBEEF; // 数据
pkt.tlp_len = 12;
if (ioctl(fd, USB4_XDOM_TX_TLP, &pkt) < 0) {
perror("ioctl");
close(fd);
return1;
}
printf("[+] TLP 注入成功\n");
close(fd);
return0;
}说明：该代码仅为概念示例，真实的 USB4 TLP 注入需要完整的 PCIe TLP 格式与正确的隧道封装，并且需要主机控制器支持调试接口。在现实攻击中，攻击者将利用专门的 USB4 设备硬件来执行此类注入。
防御性检测
# usb4_monitor.py — 监控 /sys/kernel/debug/thunderbolt 中的隧道统计
import os
import time
THUNDERBOLT_DEBUG = "/sys/kernel/debug/thunderbolt"
def check_tunnel_errors(domain="domain0"):
path = os.path.join(THUNDERBOLT_DEBUG, domain, "registers")
try:
with open(path, "r") as f:
content = f.read()
if"error"in content.lower():
print("[!] USB4 控制器报告异常")
print(content)
except FileNotFoundError:
print("[-] USB4 调试文件系统未挂载")
if __name__ == "__main__":
whileTrue:
check_tunnel_errors()
time.sleep(5)防御与加固
强制 IOMMU 严格模式
在 Linux 内核启动参数中添加 intel_iommu=on iommu=pt 或 amd_iommu=force，确保 IOMMU 始终启用。对于 USB4 域，配置 thunderbolt.iommu_dma_protection=1（内核 5.10+ 支持），强制每个隧道端点使用独立的 IOMMU 上下文，并且不允许直通。
启用 USB4 安全认证
USB4 规范定义了基于端口密钥和证书的认证机制（USB4 Authentication），主机应强制要求设备在建立 PCIe 隧道前完成认证。Linux 可通过 thunderbolt.authenticate=1 内核参数启用，并要求用户空间守护进程 bolt 进行设备授权。
物理防护与设备控制
USB4 端口访问控制：通过 BIOS 设置或 Linux 的 usbguard限制允许连接的 USB4 设备。禁用 PCIe 隧道：如果不需要外接 PCIe 设备，可在固件中关闭 USB4 的 PCIe 隧道功能。 定期审计 IOMMU 映射：使用 iommu_monitor工具实时检查是否有新设备获得了超过预期的内存访问权限。
结语
USB4 将 PCIe 隧道带入了大众外设生态，也带来了 Thunderbolt 曾引发但未根治的 DMA 安全幽灵。IOMMU 虽然是硬件级防线，但其配置正确性依赖于固件、操作系统和 OEM 的协作，任何一环的疏漏都可能将全系统物理内存暴露给外部设备。在零信任硬件日益重要的今天，USB4 端口必须被视为潜在的网络边界，而非被动接口。