TEE Device Interface Security Protocol - TDISP翻译

TDISP 安全设备直通:TLP 规则、状态机与 DOE 绑定流程实战解析 在云计算与机密计算场景中,PCIe 设备直通面临信任边界模糊的安全挑战。TDISP(TEE Device Interface Security Protocol)基于 PCIe 的 IDE 链路加密与 TLP 事务层机制,通过 DOE 邮箱管理命令和状态机绑定流程,在设备与可信执行环境之间建立受保护的通信通道。其技术价值在于将安全策略下沉到硬件层面执行 TLP 过滤与检查,确保设备只能被指定 TEE 实例访问,即使 Hypervisor 被攻破也无法绕过。该协议广泛应用于 AI 加速卡、网卡、存储控制器等设 阅读详情

PCI_SIG工程变更通知(TDISP)

PCI-SIG 工程变更通知

标题:可信执行环境设备接口安全协议(TDISP) 日期:首次发布:2020年12月1日;修订:2022年7月27日 涉及文档:PCIe 基础规范修订版 5.0 + IDE 工程变更通知、6.0 版 发起方:超威半导体公司、ARM 有限公司、英特尔公司、微软公司

第一部分 功能变更摘要

基于虚拟化的可信执行环境(TEE)用于承载机密计算工作负载,这类工作负载可与宿主环境隔离,即无需信任虚拟机监控器(VMM)。为与传统虚拟机区分,此类 TEE 此后称为可信执行环境虚拟机(TVM)。当设备的某一部分(即“可信执行环境设备接口”,TDI——直接分配的单元,例如使用 SR-IOV 时的虚拟功能(VF))被分配给 TVM 时,需为该组合建立并维护可信执行环境。

本文档定义了可信执行环境设备接口安全协议(TDISP)——一种用于可信 I/O 虚拟化的架构,具备以下功能:

  1. 建立 TVM 与设备之间的信任关系;

  2. 保障主机与设备之间互连的安全性;

  3. 以可信方式将 TDI 附加到 TVM 或从 TVM 分离;

  4. 基于 CMA/SPDM(组件测量与认证/安全协议和数据模型)及 IDE(完整性与数据加密)提供的基础构建。

2. 变更带来的益处

系统将能够建立并维护包含一个或多个设备的组合式 TEE,从而实现在虚拟化系统环境中高效保障工作负载安全的能力。

3. 影响评估

实现并运行这一可选功能需要新的硬件和软件支持。

4. 硬件影响分析

定义了一种数据对象协议及相关机制。除这些机制外,运行安全工作负载的硬件需通过安全方式实现,并以安全方式运行。

5. 软件影响分析

实现这一功能需要新的软件支持。

6. 兼容性与互操作性(C&I)测试影响分析

需更新兼容性与互操作性测试,以处理现有寄存器中新增的已定义字段。

第二部分 变更详细说明

新增术语与缩略语

  • TEE 设备接口(TDI):支持 I/O 虚拟化的设备的分配单元。例如,TDI 可以是整个设备、非 IOV(I/O 虚拟化)功能、物理功能(PF,可能包含其下属的虚拟功能)或虚拟功能(VF)。

  • TEE-I/O:一种用于建立和管理可信执行环境(TEE)的概念框架,该环境包含来自一个或多个设备的资源组合(参见第 11 章——可信执行环境设备接口安全协议(TDISP))。

  • 可信计算基(TCB):由硬件、固件和软件组成的集合,负责执行安全策略。可信计算基内部出现的漏洞或缺陷可能会危及整个系统的安全属性;相反,计算机系统中可信计算基之外的部分,不得制造出违反安全策略、超出其被授予权限的情况。

  • TVM:可信执行环境虚拟机,如可信执行环境设备接口安全协议(TDISP)参考架构中所定义(参见第 11 章)。

参考文档修订

SPDM(安全协议和数据模型)

分布式管理任务组(DMTF)安全协议和数据模型(SPDM)规范——https://www.dmtf.org/dsp/DSP0274。IDE 要求版本 1.1 及以上,TDISP 要求版本 1.2 及以上。

具体修订内容

2.2.1.2 碎片模式(Flit Mode)的通用数据包头部字段
  • 对于带有 OHC-C(可选头部内容 - C 类)但非 IDE 传输层数据包(TLP),子流(Sub-Stream)[32:0] 字段必须为 0111b,且流 ID(Stream ID)、PR 发送计数器(PR_Sent_Counter)、K 位和 T 位字段/位为保留字段。

  • 在本规范的早期版本中,子流(Sub-Stream)是符号 3 中的 4 位(位 7:4)。现在位 7 为保留位。若“支持 TEE-I/O”(TEE-IO Supported)位已置位,则组件必须将位 7 实现为保留位;若“支持 TEE-I/O”位未置位,则组件可将位 7 视为子流的一部分。

6.33 节:IDE 的威胁模型及相关注意事项(实施说明)修订

……此类 TEE 的实现和管理细节不在 IDE 规范范围内。T 位用于 TEE 管理机制(参见第 11 章 TDISP),该机制可区分与 TEE 相关联的 TLP。IDE 机制确保 T 位(与其他 TLP 内容一样)在传输过程中是安全的。

6.33.4 IDE 传输层数据包(TLP)修订

IDE 前缀包含:

  • T 位:置位时,表示该 TLP 源自可信执行环境(参见 6.33.1 节)。

    • 若设备能力寄存器中的“支持 TEE-I/O”(TEE-IO Supported)位未置位:

      • IDE TLP 可源自可信执行环境和非可信执行环境,且 T 位的值本身不改变 IDE 中 TLP 的处理方式;本规范未定义可信执行环境的相关规则。

      • 除非本规范范围外的 TEE 管理机制已明确定义 T 位的用途,否则 T 位必须置 0。

    • 若设备能力寄存器中的“支持 TEE-I/O”位已置位,则此位必须按第 11 章 TDISP 的定义,用于 TEE 管理机制。

每个子流都有一个子流标识符:

  • 0000b——已发布请求(Posted Requests)

  • 0001b——未发布请求(Non-Posted Requests)

  • 0010b——完成包(Completions)

  • 0011b-0110b——保留

  • 0111b——在非碎片模式(NFM)下为保留;在碎片模式(FM)下,表示包含 OHC-C 但非 IDE TLP 的数据包。

  • 在本规范的早期版本中,子流是符号 3 中的 4 位(位 7:4)。现在位 7 为保留位。若设备能力寄存器中的“支持 TEE-I/O”位已置位,则组件必须将位 7 实现为保留位;若“支持 TEE-I/O”位未置位,则组件可将位 7 视为子流的一部分。

  • 1000b-1111b——可用于本规范未定义的其他用途。

某一 TLP 若要与特定的选择性 IDE 流相关联,必须满足以下条件:

  • 对于完成包,选择性 IDE 流中的流 ID 和 T 位值必须与对应的未发布请求中的流 ID 和 T 位值匹配。

  • 通过特定于实现的方式选择或排除 TLP。例如,发送方可将一个或多个内部功能发起的所有内存请求与特定的选择性 IDE 流相关联,尤其是在已知伙伴端口为根端口(Root Port),且该内部功能发起的所有请求均以系统内存为目标的情况下。

  • 若某一 TLP 不满足上述针对特定选择性 IDE 流的所有适用条件,或通过特定于实现的方式被排除,则该 TLP 不得与任何选择性 IDE 流相关联。

  • 若选择性 IDE 流控制寄存器中的“TEE 受限流”(TEE-Limited Stream)位已置位,则仅允许 T 位置位的 TLP 与该选择性 IDE 流相关联。若其他情况下本应与该选择性 IDE 流相关联但 T 位未置位的 TLP,在未启用链路 IDE(Link IDE)时,必须作为非 IDE TLP 传输;在启用链路 IDE 时,必须作为链路 IDE TLP 传输。

  • 若支持“TEE 受限流”功能,则在启用选择性 IDE 流之前,必须在两个伙伴端口中均配置“TEE 受限流”位。两个伙伴端口的“TEE 受限流”位值可不同。

软件必须配置选择性 IDE,确保伙伴端口之间整个路径上的所有链路均运行在碎片模式(FM)或非碎片模式(NFM)下。

若“支持 TEE-I/O”位已置位,对于端点上游端口(Endpoint Upstream Port):

  • 若在默认流之外的选择性 IDE 流上接收到请求,且该请求的请求方 ID(Requester ID)字段小于该流的选择性 IDE 请求方 ID(RID)关联寄存器块中的 RID 基址(RID Base)或大于 RID 限值(RID Limit),则该请求必须作为不支持的请求(Unsupported Request)处理。

  • 在碎片模式下,若“段捕获”(Segment Captured)位已置位[注:“段捕获”值表示正在应用段值——捕获的段值不用于此处定义的测试],则请求必须包含 OHC-C,且请求方段有效(RSV)位已置位,同时请求方段值必须与选择性 IDE RID 关联寄存器块中的段基址(Segment Base)值匹配。

  • 若在默认流之外的选择性 IDE 流上接收到完成包,且该完成包的完成方 ID(Completer ID)字段小于该流的选择性 IDE RID 关联寄存器块中的 RID 基址或大于 RID 限值,则该完成包必须作为意外完成包(Unexpected Completion)处理。

  • 在碎片模式下,若“段捕获”位已置位,则完成包必须包含 OHC-A5,且完成方段值必须与选择性 IDE RID 关联寄存器块中的段基址值匹配。

若“支持 TEE-I/O”位已置位,对于根端口(Root Port):

  • 若在根端口作为 IDE 终点(IDE Terminus)的选择性 IDE 流上接收到请求,且该请求的请求方 ID 字段小于该流的选择性 IDE RID 关联寄存器块中的 RID 基址或大于 RID 限值,则该请求必须作为不支持的请求处理。

  • 在碎片模式下,若请求方段有效(RSV)位已置位,则请求方段值必须与选择性 IDE RID 关联寄存器块中的段基址值匹配。

  • 若在根端口作为 IDE 终点的选择性 IDE 流上接收到完成包,且该完成包的完成方 ID 字段小于该流的选择性 IDE RID 关联寄存器块中的 RID 基址或大于 RID 限值,则该完成包必须作为意外完成包处理。

  • 在碎片模式下,若完成包包含 OHC-A5,则完成方段值必须与选择性 IDE RID 关联寄存器块中的段基址值匹配。

选择性 IDE 流与多播(参见 6.14 节)的配合使用不在本规范范围内。

6.33.8 其他 IDE 规则修订

非发布 IDE 请求规则:

  • 若设备能力寄存器中的“支持 TEE-I/O”位未置位,非发布请求的请求方必须检查对应的接收完成包是否使用与该非发布请求关联的相同流 ID 和相同 T 位值返回;若不匹配,则为 IDE 检查失败错误(IDE Check Failed error),请求方必须将相关 IDE 流切换至不安全(Insecure)状态。

  • 若设备能力寄存器中的“支持 TEE-I/O”位已置位,非发布请求的请求方必须检查对应的接收完成包是否使用与该非发布请求关联的相同流 ID 返回;若不匹配,则为 IDE 检查失败错误,请求方必须将相关 IDE 流切换至不安全状态。

7.9.26.2 IDE 能力寄存器(偏移量 04h)修订
字段说明
TEE 受限流支持(TEE-Limited Stream Supported)置位时,表示支持“TEE 受限流”功能(参见 7.9.26.5.2 节)。
7.9.26.5.2 选择性 IDE 流控制寄存器修订
位位置寄存器说明属性
23TEE 受限流(TEE-Limited Stream):置位时,要求仅 T 位置位的请求可与该流相关联。读/写(RW)/只读(RO)/保留并预定义(RsvdP)
必须在“选择性 IDE 流启用”(Selective IDE Stream Enable)位为 0 时配置此位,此时该位为读/写;当“选择性 IDE 流启用”位为 1 时,采样此位的设置,该字段/位变为只读,读取时返回采样值,且在“选择性 IDE 流启用”位保持为 1 期间一直为只读。若“TEE 受限流支持”位未置位,则此位为保留位。默认值为 0b。
7.5.3.3 设备能力寄存器(偏移量 04h)修订

在这里插入图片描述

位位置寄存器说明属性
30TEE-I/O 支持(TEE-IO Supported):置位时,表示该功能实现了可信执行环境设备接口安全协议(TDISP)所描述的 TEE-I/O 功能(参见第 11 章)。硬件初始化(HwInit)
附录 L:IDE TLP 示例(图 L-2)修订

(注:此处为图表修订,保留原文图表结构,核心修订为在 TLP 头部字段中明确 T 位与 TEE-I/O 的关联逻辑,确保与前文 T 位定义一致。)
在这里插入图片描述

新增第 11 章:可信执行环境设备接口安全协议(TDISP)

包含来自一个或多个设备和主机资源组合的可信执行环境(TEE),需要建立和管理信任关系的机制。本文中,“TEE-I/O”指用于执行此类操作的概念框架。本章定义了一种供主机和设备参与 TEE-I/O 的特定架构(参见图 11-1)。TEE-I/O 基于现有设备直接分配给虚拟机的能力(如 SR-IOV(第 9 章)和 ATS(第 10 章))构建,以建立可信执行环境虚拟机(TVM)。所有非 TVM 的虚拟机均称为传统虚拟机(Legacy VM)。在 TEE-I/O 中,TVM 可能不信任 VMM,因此提供了相应机制,使 TVM 可基于其使用的底层硬件做出信任决策。尽管 TVM 无需信任 VMM,但 VMM 仍像在非 TEE-I/O 使用场景中一样,执行资源分配和系统管理功能,且执行方式需确保结果可验证,同时防止 VMM 绕过相关 TVM 的安全机制。默认信任 VMM 的传统虚拟机可与 TVM 在同一系统中共存。

在这里插入图片描述

图 11-1 包含示例主机、设备及逻辑通信路径的概念视图

(注:图表内容为架构示意,核心元素包括:支持 TEE-I/O 的主机(含 TEE 安全管理器 TSM、TVM、VMM、传统虚拟机、PF 驱动)、支持 TEE-I/O 的设备(含设备安全管理器 DSM、物理功能 PF、TDI),以及 SPDM、TDISP、MMIO、DMA 等通信路径。)

TEE 安全管理器(TSM) 是主机中的逻辑实体,属于 TVM 的可信计算基(TCB),负责在主机上执行安全策略。设备安全管理器(DSM) 是设备中的逻辑实体,可由 TSM 纳入 TVM 的可信计算基,负责在设备上执行安全策略。

可信执行环境设备接口(TDI)安全协议(TDISP)定义了支持 TEE-I/O 虚拟化的设备架构,具备以下功能:

  1. 建立 TVM 与设备之间的信任关系;

  2. 保障主机与设备之间互连的安全性;

  3. 以可信方式将 TDI 附加到 TVM 或从 TVM 分离。

尽管 TDISP 是基于上述 TEE-I/O 定义的,但它本身可作为独立的设备规范使用。只要系统以适当方式支持 TDISP 所需的主机功能,此类设备也可在采用 TEE-I/O 以外安全架构的系统中运行。

TDISP 既针对 TDI 本身定义了要求,也针对实现 TDI 的整个设备定义了要求。在具体场景中,TDI 可以是整个设备、非 IOV 功能、PF(可能包含其下属的 VF)或 VF。尽管允许(且通常预期)TDI 可被分配给传统虚拟机,但 TDISP 的核心关注点并非此类使用场景。

实施说明:未来 TEE 扩展 子功能 I/O 虚拟化技术的 TEE 扩展将在本规范的未来修订版中涵盖。

11.1 TEE-I/O 安全模型与设备的关联概述

TEE-I/O 安全模型主要适用于设备资源直接分配给虚拟机的系统,本章通常默认此使用场景。但符合 TDISP 规范的设备也可能以其他方式使用,本规范不禁止此类使用,但相关内容不在本规范范围内。

TEE-I/O 将所有资源(包括各类内存、主机处理器、TDI,在某些情况下还包括内部状态)分为以下两类:

  • 可分配给 TEE 的资源:具备分配给 TEE 所需的信任/安全能力,分配给 TEE 后,这些资源成为“TEE 所有的资源”;

  • 不可分配给 TEE 的资源:要么不具备分配给 TEE 所需的信任/安全能力,要么通过特定于实现的机制被排除。这些资源通常在系统功能中发挥关键作用,因此通常需要对其进行适当的安全保护,但具体保护方式不在本规范范围内。

TEE-I/O 安全模型不要求 TVM 信任 VMM。因此,支持硬件辅助 I/O 虚拟化的设备(如 SR-IOV)需要安全扩展,以确保设备的虚拟化模型不会允许或要求可信计算基外的软件干预影响 TVM 数据(传输中或静止在设备中)的机密性和/或完整性。TDISP 的核心目标是定义符合 TDISP 规范的设备要求,以及支持 TDISP 架构所需的设备外必要元素;所需的其他系统能力不在 TDISP 范围内。

分配给 TVM 的设备中存储的 TVM 数据、代码和执行状态必须防范以下风险:

  • 机密性泄露:来自 TVM 可信计算基外的实体(如其他 TVM、VMM 等,包括固件、软件或硬件)的读取访问;

  • 完整性破坏:来自 TVM 可信计算基外的实体(如其他 TVM、VMM 等,包括固件、软件或硬件)的修改。

本安全模型通常不要求防范针对 TVM 的拒绝服务攻击,但系统可能会要求 TVM 不得具备对其他 TVM、VMM 或平台上运行的其他虚拟机发起拒绝服务攻击的能力。仅靠 TSM 可能无法完全具备防御平台拒绝服务攻击的能力,因此执行这一安全属性是 TSM、VMM、设备和 DSM 的共同责任,且不在本规范范围内。

为保障 TVM 及其与设备之间传输数据的机密性和完整性,TVM 到设备的硬件辅助 I/O 虚拟化方案必须解决以下问题:

  1. 设备身份认证与测量报告:设备身份(如厂商 ID、设备 ID)可能被恶意伪造;设备上运行的固件可能存在安全漏洞或被篡改;设备调试接口可能被用于获取设备硬件的底层访问权限,进而影响设备的安全属性。TVM 必须能够以加密方式验证设备身份、设备上运行的固件组件身份以及设备的安全状态(如调试是否激活)。CMA/SPDM 用于满足这些要求。

  2. 设备到主机的通信安全:物理访问可能被用于篡改主机与设备之间传输的数据。传输必须通过加密保护,为 TVM 数据提供机密性、完整性和重放保护,且此类方案还必须防范违反生产者-消费者排序的行为。IDE 用于满足这些要求。在某些情况下(如 RCiEP(根复合体集成端点)),可能通过架构设计确保通信不受篡改,因此可能无需使用 IDE。TSM 和 DSM 均有责任确保设备/主机(以及使用对等通信时的设备/设备)通信通过 IDE 或满足使用场景要求的其他方式实现安全保护。

  3. TEE 设备接口(TDI)管理:VMM 配置的 DMA 和中断重映射表可能被 VMM 篡改;VMM 对这些表的管理(如 IOMMU TLB 管理、设备 TLB 管理、页面请求处理等)也可能被 VMM 篡改,进而影响 TVM 与设备交互的安全性。设备必须支持锁定 TDI 的配置、以可信方式报告配置、将 TDI 安全置于运行状态,以及在 TDI 从 TVM 分离时安全销毁配置。本章定义了用于管理 TDI 安全状态的机制。

  4. 设备安全架构:管理接口(如 PF)可能被用于影响 TVM 所使用 TDI 的安全属性。设备的安全架构必须为设备中的 TVM 数据提供隔离和访问控制,以防范来自 TVM 信任边界外实体的攻击。本章定义了部分设备安全架构要求,但特定实现可能还需满足本规范范围外的其他要求。

本章定义了主机和设备为兼容 TEE-I/O 框架所需实现的有线协议和安全目标,以及实现指定安全目标所需具备的能力。此类能力的具体实现方式和逻辑实体的物理表现形式不在本规范范围内。
在这里插入图片描述

11.2 TDISP 规则

在这里插入图片描述

如图 11-3 所示,每个 TDI 由特定的 DSM 管理,在该 DSM 的域内,每个 TDI 必须有唯一的标识符(称为 INTERFACE_ID),该标识符在所有 TSM/DSM 消息中用于指示对应的 TDI。TVM 发起的 MMIO 请求经主机转换后,根据主机物理地址(HPA)定向到相应的 TDI;TDI 生成的请求包含承载该 TDI 的功能的请求方 ID(RID),有时还包含进程地址空间 ID(PASID)。

图 11-3 请求标识

(注:图表示意 TVM 与设备间请求标识的映射关系,包括 INTERFACE_ID、HPA、RID、RID+PASID 等标识符的对应逻辑。)

INTERFACE_ID 由 FUNCTION_ID 字段(标识承载 TDI 的设备功能)和保留字段(用于未来扩展)组成(参见图 11-4 TDI 标识符——INTERFACE_ID 和表 1 INTERFACE_ID 定义)。在 FUNCTION_ID 中,功能号(Function Number)和设备号(Device Number)由设备/DSM 分配;总线号(Bus Number)和段号(Segment Number)在系统枚举时分配,且在 TDI 处于 CONFIG_LOCKED(配置锁定)和 RUN(运行)状态时不得更改。若设备已知段号且请求方段有效(Requester Segment Valid)位已置位,则请求方段值必须与设备的段号匹配。DSM 必须确保仅对有效的 TDI 进行寻址。

在这里插入图片描述

图 11-4 TDI 标识符——INTERFACE_ID

(注:图表示意 INTERFACE_ID 的结构,包含 4 字节 FUNCTION_ID 和 8 字节保留字段。)

表 1 INTERFACE_ID 定义

偏移量字段大小(字节)说明
0FUNCTION_ID4标识承载 TDI 的设备功能:
15:0 位——请求方 ID(RID)
23:16 位——请求方段(若请求方段有效位未置位,则为保留)
24 位——请求方段有效
31:25 位——保留
4保留8保留

设备中的每个 TDI 均关联一个 TDISP 状态机(参见图 11-5)。

image.png

图 11-5 TDISP 状态机

(注:图表示意 TDI 的状态转换逻辑,包含 CONFIG_UNLOCKED(配置未锁定)、CONFIG_LOCKED(配置锁定)、RUN(运行)、ERROR(错误)四个核心状态,以及各状态间通过特定请求(如 LOCK_INTERFACE_REQUEST、START_INTERFACE_REQUEST 等)的转换规则。)

TSM 通过 TDISP 状态机的安全状态转换,管理 TDI 的安全生命周期(如锁定 TDI 配置以准备分配给 TVM、将 TDI 转换至运行状态、将 TDI 从 TVM 分离等)。TDI 在 CONFIG_LOCKED 和 RUN 状态下视为“已锁定”,在 ERROR 和 CONFIG_UNLOCKED 状态下视为“未锁定”。

对于支持分配给传统虚拟机的 TDI,若其被分配给传统虚拟机,VMM 会在 CONFIG_UNLOCKED 状态下分配该 TDI,且 TSM 必须确保该 TDI 保持此状态,除非该 TDI 从传统虚拟机中移除并准备重新分配给其他 TDI。

TDISP 要求拒绝某些 TLP,即首先按适用于所有其他 TLP 的规则处理该 TLP,然后再应用 TDISP 特定规则。若判定需拒绝该 TLP,则相关 TDI 必须按指示转换至 ERROR 状态,但无需对该 TLP 执行进一步的错误报告或日志记录(可根据具体情况,将请求作为不支持的请求处理、将完成包作为意外完成包处理,或丢弃该 TLP)。

用于 TDISP 的 IDE 流也可用于非 TDISP TLP,但需满足:

  • 对于此类 TLP,传输的 TLP 中 T 位必须置 0,接收时必须忽略 T 位(如 6.33.4 节定义);

  • DSM 必须确保此类 TLP 不得访问 TVM 的机密数据。

各状态的安全属性及转换规则如下:

11.2.1 CONFIG_UNLOCKED(配置未锁定)状态
  • 这是默认状态。在 CONFIG_UNLOCKED 状态下,VMM 配置 TDI 以分配给 TVM;

  • 此状态下,TDI 无需保护存入其中的机密数据,TVM 不应在此状态下向 TDI 存入机密数据;

  • 此状态下,必须拒绝源自 TVM 的内存请求(以 T 位置位标识)(参见 11.2.1 节);

  • 响应 STOP_INTERFACE_REQUEST 消息,可从任何其他状态转换至此状态。当 TDI 转换至 CONFIG_UNLOCKED 状态时,DSM 必须确保设备在该 TDI 上下文中持有的所有 TVM 机密数据不得以明文形式暴露在设备外,且应尽可能确保 TVM 数据的密文也不暴露在设备外。

11.2.2 CONFIG_LOCKED(配置锁定)状态
  • VMM 完成 TDI 配置后,会请求 TSM 通过将 TDI 转换至 CONFIG_LOCKED 状态来锁定 TDI 配置;

  • 仅响应 LOCK_INTERFACE_REQUEST 消息,DSM 才可将 TDI 转换至 CONFIG_LOCKED 状态;

  • 此状态下,必须拒绝源自 TVM 的内存请求(以 T 位置位标识)(参见 11.2.1 节);

  • 若需使用 IDE 保障与设备之间传输的安全性,LOCK_INTERFACE_REQUEST 必须指示要绑定到 TDI 的 IDE 流的流 ID;

  • 进入此状态时,DSM 必须执行所有必要操作以锁定 TDI 配置,然后开始跟踪 TDI 的配置或安全相关变更;检测到变更时,必须将其视为错误,并将 TDI 转换至 ERROR 状态。表 11.2.6“锁定的设备配置”中指定了应锁定和跟踪的架构配置寄存器示例列表,通常 DSM 还需跟踪其他设备特定配置(如工作队列配置、MAC 地址、存储卷等设备特定配置);

  • TVM 可从 DSM 获取承载 TDI 的设备的身份和测量信息,若适用,还可验证 TSM 是否已在主机与设备之间建立 IDE 流;TVM 可请求 TSM 通过向 DSM 发送 GET_DEVICE_INTERFACE_REPORT 请求获取 TDI 配置;

  • TVM 可评估设备身份、测量信息以及 TDI 报告,以判断设备是否满足 TVM 的安全要求;

  • 若 TVM 认可该设备,可请求 TSM 将 TDI 转换至 RUN 状态。

11.2.3 RUN(运行)状态
  • TDI 资源处于运行状态,允许 TVM 访问和管理;

  • 进入此状态时,DSM 必须继续跟踪 TDI 的配置或安全相关变更;检测到变更时,必须将其视为错误,并将 TDI 转换至 ERROR 状态。

11.2.4 ERROR(错误)状态
  • TDI 不得暴露 TVM 的机密数据;

  • 此状态下,必须拒绝源自 TVM 的内存请求(以 T 位置位标识)(参见 11.2.1 节);

  • TDI 必须按 11.2.1 节“TLP 规则”的定义限制 TLP 操作;

  • 处于 ERROR 状态时,TDI 可能仍持有 TVM 的机密数据,可延迟清除这些数据,直至收到 STOP_INTERFACE_REQUEST 消息将 TDI 转换至 CONFIG_UNLOCKED 状态;

  • 允许(但不要求)TDI 从 ERROR 状态自动转换至 CONFIG_UNLOCKED 状态,但前提是 TDI 已先清除所有 TVM 机密数据。

在 CONFIG_LOCKED 和 RUN 状态下,以下情况必须视为错误,并导致 TDI 转换至 ERROR 状态:

  • 影响 TDI 配置或安全的 TDI 配置变更(配置写入的完成状态不受影响,参见 11.2.6 节“DSM 对锁定 TDI 配置的跟踪与处理(参考性)”);

  • 请求方 ID(RID)变更;

  • 使用功能级重置(Function Level Reset)重置 TDI(PF 重置影响所有下属 VF TDI,VF 重置仅影响自身);

  • 绑定到 TDI 的任何 IDE 流转换至不安全状态;

  • 接收到带毒 TLP(Poisoned TLP),或在设备中检测到与该 TDI 相关的数据存在不可恢复的数据完整性错误;

  • 其他影响信任属性的设备特定情况或配置变更。

STOP_INTERFACE_REQUEST 消息可用于将 TDI 转换至 CONFIG_UNLOCKED 状态。当 TDI 转回 CONFIG_UNLOCKED 状态时,必须确保设备持有的所有 TVM 机密数据不得以明文形式暴露在设备外;应尽可能确保 TVM 机密数据的密文也不暴露在设备外。

TSM 可在 CONFIG_LOCKED 和 RUN 状态下发送 GET_DEVICE_INTERFACE_REPORT 请求;可在所有状态下发送 GET_DEVICE_INTERFACE_STATE 请求。

部分 TDI 可能支持与其他设备的对等(P2P)通信,用于此类通信的 IDE 流的流 ID 通过 BIND_P2P_STREAM_REQUEST 消息配置到设备中。仅当 TDI 处于 RUN 状态时,DSM 才允许接收此消息。设备必须支持 ATS(地址转换服务)且已启用 ATS,才能支持 TVM 分配的 TDI 之间的对等通信。TSM 和 VMM 必须协调使用 ACS(访问控制服务)机制,将设备对等通信流量重定向至根复合体(Root Complex);仅当与该选择性 IDE 流相关联的 TLP 确实在两个对等设备之间传输(而非与根复合体之间传输)时,TSM 才可发送 BIND_P2P_STREAM_REQUEST 消息。

某些配置要求 TDI 发起的所有请求均发送至根复合体,即使设备已获取看似指向 TDI 内部或设备其他位置资源的转换地址。强烈建议设备实现重定向功能,将所有此类请求发送至根复合体;DSM 必须公示此类功能的可用性,以便 TSM 为 TDI 和系统其他部分建立正确配置。

部分 TDI 可能支持使用 SET_MMIO_ATTRIBUTE_REQUEST 消息更新与其关联的一个或多个 MMIO 范围的属性。

TDI 不得依赖 I/O 资源和 I/O 请求为 TVM 提供功能;I/O 资源不得危及 TVM 数据的机密性或完整性。

无需保障对 TDI 的配置请求(Configuration Requests)的安全性。

11.2.1 TLP 规则

本节定义与 TVM 相关联的 TLP 规则。在可确保通信不被篡改的情况下,可能无需使用 IDE,但仍可能需要与 IDE 定义的结构(尤其是 T 位)等效的机制,具体实现方式不在本规范范围内。在所有情况下,设备必须确保“IS_NON_TEE_MEM”属性未置位的设备内存,仅可在已授权 TVM 的上下文中(使用 IDE 时,以 T 位置位标识)进行读写。

在所有情况下,TDISP 不要求对无安全需求的流量通过 IDE 或其他方式进行保护,但在特定平台中可能存在额外安全要求(例如,对主机与特定设备之间的所有 TLP 应用 IDE)。

11.2.1.1 TDI 作为请求方的规则
  • 在要求使用 IDE 的系统中,处于 CONFIG_LOCKED 或 RUN 状态的 TDI 仅可在绑定到该 TDI 的 IDE 流上传输 T 位置位的 TLP;

  • 所有与对等 IDE 流无关的 TLP,若已配置默认 IDE 流,则必须使用默认 IDE 流;

  • 内存读请求仅可在 RUN 状态下发起,且必须置位 T 位;

  • TDI 在 RUN 状态下发起的内存读请求,仅当 TDI 仍处于 RUN 状态时,对应的完成包才可正常处理,否则必须拒绝;

  • RUN 状态下的 TDI 必须忽略接收完成包中的 T 位值;

  • 除 MSI/MSI-X 中断外的内存写请求,仅可在 RUN 状态下发起,且必须置位 T 位;

  • TDI 所承载功能的配置空间中的 MSI 能力,无需具备可信配置;对于 MSI-X,TVM 可通过可信方式编程 MSI-X 表和 MSI-X PBA(待处理中断数组);

  • CONFIG_LOCKED 状态下的 TDI 仅可在 T 位未置位时发起 MSI/MSI-X;RUN 状态下的 TDI 生成内存写请求以使用 MSI 请求服务时,必须遵循以下规则:

    • 使用从功能的 MSI 能力获取的地址/数据对生成的 MSI,必须置位 T 位;

    • 使用从 TDI 的 MSI-X 能力获取的地址/数据对生成的 MSI,若 MSI-X 表未被锁定且未在 DEVICE_INTERFACE_REPORT 中报告,则必须置位 T 位;否则,必须置位 T 位。

若支持锁定和报告 MSI-X 表,TEE-I/O 兼容设备必须分配 MSI-X 表和 PBA,确保 MSI-X 表和 PBA 的全部内容可映射到独立的隔离处理器页面。MSI-X 表和 PBA 的基地址必须在支持的平台上对齐到最小处理器页面大小,建议 64KB 对齐以实现跨不同处理器架构的兼容性。

若支持 ST(共享事务)模式操作,TEE-I/O 兼容设备必须将 ST 表(若支持)置于 MSI-X 表中。

11.2.1.2 TDI 作为完成方的规则
  • 对于目标为“IS_NON_TEE_MEM”(参见 11.3.22 节“SET_MMIO_ATTRIBUTE_REQUEST”)属性未置位的设备内存的接收内存请求,仅当满足以下所有条件时才可正常处理,否则必须拒绝:

    • 请求的 T 位已置位;

    • TDI 处于 RUN 状态;

    • 若要求使用 IDE,请求是在绑定到 TDI 的流 ID 上接收的;

  • 除 RUN 状态外,其他状态下接收到 T 位置位且目标为设备内存的请求时,必须拒绝;

  • TDI 对目标为“IS_NON_TEE_MEM”属性已置位的 MMIO 的接收内存请求的处理,不受 TDISP 状态影响;

  • TDI 返回的完成包中的 T 位值,必须与对应请求中的 T 位值匹配。

ATS 失效请求、失效完成包、页面请求消息和 PRG(页面请求组)响应有特定要求,定义于 11.4.10 节。

PCI-SIG 未定义的 VDM(供应商定义消息),必须由供应商指定为 TDI 特定或非 TDI 特定。

仅当 T 位已置位时,TDI 才可在 CONFIG_LOCKED、RUN 和 ERROR 状态下传输和正常处理接收的 TDI 特定消息。

11.2.2 TDISP 消息传输

所有 TDISP 消息必须通过符合“安全 CMA/SPDM”(参见 6.31.4 节“安全 CMA/SPDM”)定义的安全消息,在 TSM 与 DSM 之间传输,且这些安全消息需在 TSM 与 DSM 之间建立的安全会话内传输(符合 [SPDM] 规范)。

TDISP 要求 TSM 和 DSM 支持 AES-256-GCM 作为“带关联数据的认证加密(AEAD)”算法,以保护通过安全消息传输的数据。安全消息的随机数据字段不得用于 TDISP 消息或 IDE 密钥管理协议消息,且该字段长度必须为 0。

设备的功能 0(Function 0)必须支持 DOE(数据对象交换)扩展能力,以建立 SPDM 会话并传输安全消息。

[SPDM] 规范中,请求方(Requester)角色由主机中的 TSM 承担,响应方(Responder)角色由 DSM 承担。TSM 可使用不可信通道(如通过 VMM 代理)访问传输机制。

TDISP 消息的传输方式如下:

  • 请求方(TSM)必须使用 [SPDM] 规范中的“VENDOR_DEFINED_REQUEST”格式;

  • 响应方(DSM)必须使用 [SPDM] 规范中的“VENDOR_DEFINED_RESPONSE”格式;

  • “VENDOR_DEFINED_REQUEST”和“VENDOR_DEFINED_RESPONSE”消息的“StandardID”字段,必须包含 [SPDM] 规范中分配给 PCI-SIG 的标识值;

  • “VENDOR_DEFINED_REQUEST”和“VENDOR_DEFINED_RESPONSE”消息的“VendorID”字段,必须包含分配给 PCI-SIG 的标识值;

  • “VendorDefinedReqPayload”/“VendorDefinedRespPayload”的第一个字节为协议 ID(Protocol ID),必须包含 01h 以标识 TDISP。

TDISP 消息构成“VendorDefinedReqPayload”或“VendorDefinedRespPayload”中的请求或响应负载。“VENDOR_DEFINED_REQUEST”/“VENDOR_DEFINED_RESPONSE”必须作为“安全消息”(符合 [安全 SPDM] 规范)的“应用数据”(Application Data)字段。

封装结构如图 11-6 所示:

image.png

图 11-6 TDISP 请求/响应封装

(注:图表示意 TDISP 请求/响应在安全消息中的封装结构,包含会话 ID、应用数据长度、消息认证码、请求/响应头部、请求/响应负载等字段,明确加密数据与明文数据的范围及 MAC 覆盖范围。)

若接收到的 TDISP 消息未通过 [安全 SPDM] 规范定义的安全方式传输,则不得使用该消息,且不得返回响应。

11.2.3 请求方(TSM)要求

请求方不得超出特定 DSM 允许的未完成请求数量(由 NUM_REQ_ALL 指示),也不得超出特定 TDI 允许的未完成请求数量(由 NUM_REQ_THIS 指示)(参见表 9“TDISP_CAPABILITIES”)。若请求方已向某一响应方发送请求,且希望向同一响应方发送后续请求,则必须等待以下操作完成后再发送后续请求:

  1. 收到响应方对未完成请求的响应;

  2. 等待响应超时;

  3. 从传输层收到请求消息传输失败的指示。

请求方可向不同响应方同时发送请求消息。

11.2.4 响应方(DSM)要求

响应方无需同时处理超过 NUM_REQ_THIS 个请求。若响应方未准备好接收新请求消息,必须要么返回“TDISP_ERROR”响应消息(ERROR_CODE=BUSY),要么静默丢弃请求消息。

若响应方正处理来自某一请求方的请求消息,可返回“ERROR_CODE=BUSY”响应。

若响应方支持与多个请求方同时通信,需通过安全消息中的会话 ID(Session ID)区分不同请求方。

11.2.5 时序要求

TDISP 继承用于封装消息的 SPDM 协议的时序要求。

11.2.6 DSM 对锁定 TDI 配置的跟踪与处理(参考性)

DSM 必须跟踪对承载处于 CONFIG_LOCKED 或 RUN 状态 TDI 的物理功能(PF)、虚拟功能(VF)或非 IOV 功能的任何配置寄存器或其他可变更设备配置控制的修改尝试。具体需跟踪的内容取决于实现,由于设备的安全属性依赖于这些机制的正确实现,强烈建议精通安全硬件构建与验证的人员深度参与所有实现的设计与验证。

表 3 提供了有关架构定义寄存器的一般指导。设备厂商必须评估设备特定寄存器,以确定是否允许修改这些寄存器;还必须评估映射到设备内存空间或配置空间的其他设备特定寄存器,以确定是否必须锁定和跟踪这些寄存器的修改。

表 2:架构寄存器的 DSM 跟踪与处理示例

寄存器/能力/扩展能力说明寄存器修改的示例响应
缓存行大小(Cache Line Size)、延迟计时器(Latency Timer)、中断线(Interrupt Line)允许修改无特殊响应
命令寄存器(Command)参见说明清除以下任意位,将导致该功能承载的 TDI 转换至 ERROR 状态:
内存空间启用(Memory Space Enable)
总线主控启用(Bus Master Enable)
其他位的修改允许
状态寄存器(Status)、BIST 寄存器(BIST Register)允许修改无特殊响应
基地址寄存器(Base Address Registers)、扩展 ROM 基地址(Expansion ROM Base Address)错误将承载的 TDI 转换至 ERROR 状态
电源管理能力(Power Management Capability)参见说明若电源转换导致功能丢失状态,则设备将该功能承载的 TDI 转换至 ERROR 状态
只读寄存器、硬件初始化寄存器、用于选择读取数据的寄存器(如电源预算数据选择寄存器)-排除在本表之外,DSM 必须确保修改这些寄存器不会影响 TDI 的安全性
设备控制寄存器(Device Control)、设备控制 2 寄存器(Device Control 2)、设备控制 3 寄存器(Device Control 3)参见说明修改以下任意位的状态,将导致该功能承载的 TDI 转换至 ERROR 状态:
扩展标签字段启用(Extended Tag Field Enable)
幻影功能启用(Phantom Functions Enable)
发起功能级重置启用(Initiate Function Level Reset Enable)
无窥探(No Snoop)
10 位标签请求方启用(10-bit Tag Requester Enable)
14 位标签请求方启用(14-bit Tag Requester Enable)
其他位的修改允许
设备状态 2 寄存器(Device Status 2)、设备状态 3 寄存器(Device Status 3)允许修改无特殊响应
链路控制寄存器(Link Control)、链路控制 2 寄存器(Link Control 2)、链路控制 3 寄存器(Link Control 3)、16.0 GT/s 控制寄存器(16.0 GT/s Control)、32.0 GT/s 控制寄存器(32.0 GT/s Control)、64.0 GT/s 控制寄存器(64.0 GT/s Control)允许修改无特殊响应
链路状态寄存器(Link Status)、链路状态 2 寄存器(Link Status 2)、16.0 GT/s 状态寄存器(16.0 GT/s Status)、32.0 GT/s 状态寄存器(32.0 GT/s Status)、64.0 GT/s 状态寄存器(64.0 GT/s Status)允许修改若修改这些寄存器导致链路断开(Link Down),则设备中配置的 IDE 流转换至不安全状态,绑定到这些流的 TDI 随之转换至 ERROR 状态
MSI、MSI-X参见说明若 MSI-X 表已锁定并报告,则任何修改导致转换至 ERROR 状态;否则允许修改
次级 PCIe(Secondary PCIe)、物理层 16.0 GT/s(Physical Layer 16.0 GT/s)、物理层 32.0 GT/s(Physical Layer 32.0 GT/s)、物理层 64.0 GT/s(Physical Layer 64.0 GT/s)、接收器(Receiver)、碎片错误注入处的通道裕量(Lane Margining at the Flit Error Injection)允许修改若修改这些寄存器导致链路断开,则设备中配置的 IDE 流转换至不安全状态,绑定到这些流的 TDI 随之转换至 ERROR 状态
ACS(访问控制服务)、延迟容限报告(Latency Tolerance Reporting)允许修改无特殊响应
L1 PM 子状态(L1 PM Substates)允许修改若修改这些寄存器导致链路断开,则设备中配置的 IDE 流转换至不安全状态,绑定到这些流的 TDI 随之转换至 ERROR 状态
高级错误报告(Advanced Error Reporting)允许修改如 6.2.3.2.2 节所述,错误掩码寄存器设置控制检测到错误的报告,但不阻止错误检测
增强分配(Enhanced Allocation)、可调整大小 BAR(Resizable BAR)、VF 可调整大小 BAR(VF Resizable BAR)、ARI(替代路由 ID)、PASID(进程地址空间 ID)错误将承载的 TDI 转换至 ERROR 状态
虚拟通道(Virtual Channel)、多功能虚拟通道(Multi-Function Virtual Channel)允许——参见说明当 TC/VC 映射变更或仲裁表更新时,设备必须强制执行事务排序
供应商特定(Vendor Specific)、供应商特定扩展(Vendor Specific Extended)、指定供应商特定(Designated Vendor Specific)参见说明由供应商根据 TDISP 提供的安全原则分析
多播(Multicast)错误TEE-I/O 兼容设备不支持启用多播机制,将承载的 TDI 转换至 ERROR 状态
动态功率分配(Dynamic Power Allocation)允许设备必须防止自身运行超出规格;若设备无法通过节流、频率控制等机制在功率分配范围内可靠运行,则将承载的 TDI 转换至 ERROR 状态
TPH 请求方(TPH Requester)参见说明由供应商根据 TDISP 提供的安全原则分析
精确时间管理(Precision Time Management)、层级 ID(Hierarchy ID)、原生 PCIe 机框管理(Native PCIe Enclosure Management)、替代协议(Alternate Protocol)允许修改无特殊响应
协议多路复用(Protocol Multiplexing)允许修改支持 PMUX(协议多路复用)的 TEE-I/O 兼容设备,不得使用 PMUX 数据包传输或接收处于 CONFIG_LOCKED 或 RUN 状态的 TDI 的事务;若修改这些寄存器导致链路断开,则设备中配置的 IDE 流转换至不安全状态,绑定到这些流的 TDI 随之转换至 ERROR 状态
影子功能(Shadow Functions)不适用TEE-I/O 使用场景不允许使用影子功能
数据对象交换(Data Object Exchange)允许修改无特殊响应
完整性与数据加密(Integrity and Data Encryption)参见说明修改绑定到锁定 TDI 的流的流控制寄存器、选择性 IDE RID 关联寄存器或选择性 IDE 地址关联寄存器,属于错误,设备将绑定到这些流的 TDI 转换至 ERROR 状态
地址转换服务(Address Translation Services)允许修改无特殊响应
页面请求(Page Request)、SR-IOV错误将承载的 TDI 转换至 ERROR 状态
VPD( vital product data,重要产品数据)允许修改无特殊响应
11.2.7 TVM 对 TDI 的认可

TVM 将 TDI 纳入其可信计算基(TCB)前,必须确认以下问题:

  1. 承载 TDI 的设备的身份,以及设备报告的测量信息是否可接受?

  2. TSM 与 DSM 之间是否已建立 SPDM 安全会话?TSM 为建立 SPDM 安全会话而认证的身份,是否与报告给 TVM 的身份匹配?

  3. 若要求使用 IDE,TSM 是否已建立或验证该 TDI 使用的 IDE 流的所有 IDE 密钥?

  4. VMM 是否已按预期配置 TDI,并将 TDI 映射到 TVM 的地址空间?

TVM 通过 TSM 提供的接口查询 TSM,以获取问题 1、2、3 的答案;然后 TVM 请求从 DSM 获取 TDI 配置报告(参见 11.3.10 节“GET_DEVICE_INTERFACE_REPORT”),并可在 TSM 的支持下确定问题 4 的答案。

若所有问题的答案均为“是”,则 TVM 可将 TDI 纳入其可信计算基。

11.3 TDISP 消息格式与处理

11.3.1 TDISP 请求码

TDISP 请求码表定义了 TDISP 请求码。所有符合 TDISP 规范的实现必须使用以下 TDISP 请求码。对于不支持的请求码,必须返回“TDISP_ERROR”响应消息(ERROR_CODE=UNSUPPORTED_REQUEST)。

表 3 TDISP 请求码

消息码数值设备要求(必需/可选)合法 TDISP 状态说明
GET_TDISP_VERSION81h必需不适用此请求消息用于获取设备的 TDISP 版本
GET_TDISP_CAPABILITIES82h必需不适用获取设备的协议能力
LOCK_INTERFACE_REQUEST83h必需CONFIG_UNLOCKED将 TDI 转换至 CONFIG_LOCKED 状态
GET_DEVICE_INTERFACE_REPORT84h必需CONFIG_LOCKED、RUN获取 TDI 报告
GET_DEVICE_INTERFACE_STATE85h必需CONFIG_UNLOCKED、CONFIG_LOCKED、RUN、ERROR获取 TDI 状态
START_INTERFACE_REQUEST86h必需CONFIG_LOCKED启动 TDI(将 TDI 转换至 RUN 状态)
STOP_INTERFACE_REQUEST87h必需CONFIG_UNLOCKED、CONFIG_LOCKED、RUN、ERROR停止 TDI 并将其转换至 CONFIG_UNLOCKED 状态(若尚未处于该状态)
BIND_P2P_STREAM_REQUEST88h可选RUN绑定对等(P2P)流
UNBIND_P2P_STREAM_REQUEST89h可选RUN解绑对等(P2P)流
SET_MMIO_ATTRIBUTE_REQUEST8Ah可选RUN更新指定 MMIO 范围的属性
VDM_REQUEST8Bh可选不适用供应商定义消息请求
11.3.2 TDISP 响应码

响应消息中的“请求响应码”(Request Response Code)字段,必须指定适当的响应码(参见表 4“TDISP 响应码”)。操作成功完成时,必须返回指定的响应消息;操作失败时,必须返回“TDISP_ERROR”响应消息。未定义/不支持的响应码,必须视为“TDISP_ERROR”。

表 4 TDISP 响应码

消息码值(十六进制)要求(必需/可选)说明
TDISP_VERSION01必需设备支持的版本
TDISP_CAPABILITIES02必需设备的协议能力
LOCK_INTERFACE_RESPONSE03必需对 LOCK_INTERFACE_REQUEST 的响应
DEVICE_INTERFACE_REPORT04必需TDI 报告
DEVICE_INTERFACE_STATE05必需返回 TDI 状态
START_INTERFACE_RESPONSE06必需对“将 TDI 转换至 RUN 状态”请求的响应
STOP_INTERFACE_RESPONSE07必需对 STOP_INTERFACE_REQUEST 的响应
BIND_P2P_STREAM_RESPONSE08可选对“绑定 P2P 流”请求的响应
UNBIND_P2P_STREAM_RESPONSE09可选对“解绑 P2P 流”请求的响应
SET_MMIO_ATTRIBUTE_RESPONSE0A可选对“更新 MMIO 范围属性”请求的响应
VDM_RESPONSE0B可选供应商定义消息响应
TDISP_ERROR7F必需处理请求时出错
11.3.3 TDISP 消息格式与协议版本控制

表 5“TDISP 请求格式”定义了所有 TDISP 消息中包含的字段。除非另有规定,以下规则适用于 TDISP 中的所有请求和响应消息:

  • 枚举或其他数值范围中的保留、未指定或未分配值,保留给 TDISP 规范的未来版本定义;保留的数值和位字段必须写为 0,读取时忽略;

  • 多字节数值字段或多字节位字段的字节顺序为“小端序”(即最低字节偏移量存储最低有效字节,较高偏移量存储较高有效字节);

  • 无论大小或端序如何,所有消息字段的最高数值位均映射到该字段的最高数值分配字节,按单调递减顺序直至最低数值分配字节;

  • 所有 TDISP 消息均包含 1 字节的“TDISPVersion”字段,该字段分为两个子字段:

    • 位 7:4——主版本(Major Version):TDISP 规范的主版本,当协议修改破坏向后兼容性时,主版本递增;

    • 位 3:0——次版本(Minor Version):TDISP 规范的次版本,当协议修改保持向后兼容性时,次版本递增。

本版本 TDISP 为 V1.0,表示为 10h。

有关兼容版本协商的详细信息,参见 11.3.5 节“GET_TDISP_VERSION”。

表 5 TDISP 消息格式

偏移量字段大小(字节)说明
0TDISPVersion1TDISPVersion 字段表示规范版本,编码方式如下:
位 7:4——主版本
位 3:0——次版本
1MessageType1标识消息类型的代码(参见表 3“TDISP 请求码”和表 4“TDISP 响应码”)
2保留2保留
4INTERFACE_ID12TDI 的 ID,如 11.2 节“TDISP 规则”中定义
16TDISP 消息负载可变特定于 MessageType 的 0 个或多个字节

若检测到表 6 中定义的任何错误情况,设备必须拒绝请求并返回指定的响应码:

表 6 通用错误响应码

错误码说明
INVALID_REQUEST请求的一个或多个字段无效
VERSION_MISMATCH协议版本不支持或不是约定版本
BUSY设备因忙碌无法处理请求
UNSPECIFIED因未指定的原因出错
VENDOR_SPECIFIC_ERROR因供应商特定原因出错
INVALID_INTERFACE指定的 INTERFACE_ID 不在 DSM 的域内
11.3.4 GET_TDISP_VERSION

此请求消息用于获取设备的 TDISP 版本。在未来所有 TDISP 版本中,“TDISP_GET_VERSION”和“TDISP_VERSION”响应消息将与所有先前版本向后兼容。请求方必须通过发送主版本为 1h 的“TDISP_GET_VERSION”请求消息开始发现过程;所有响应方必须始终支持主版本为 1h 的“TDISP_GET_VERSION”请求消息,并返回包含所有支持版本的“TDISP_VERSION”响应(如“TDISP_GET_VERSION”请求消息表所述)。请求方必须参考“TDISP_VERSION”响应选择支持的通用(通常为最高)版本,并在所有后续其他请求的通信中使用该选定版本。在收到成功的“TDISP_VERSION”响应并确定双方支持的通用版本前,请求方不得发送其他请求。响应方不得对“TDISP_GET_VERSION”请求消息返回“ERROR_CODE=RESPONSE_NOT_READY”。

主机系统可使用“GET_TDISP_VERSION”确定设备是否支持 TDISP。

11.3.5 TDISP_VERSION

表 7 TDISP_VERSION

偏移量字段大小(字节)说明
负载(所有字段均为小端序)
16VERSION_NUM_COUNT(N)1版本号条目的数量,最小允许值为 1
17VERSION_NUM_ENTRY[1-N]1×N8 位版本条目,每个条目格式如下:
位 7:4——主版本号
位 3:0——次版本号
11.3.6 GET_TDISP_CAPABILITIES

用于获取响应方的 TDISP 能力。TDISP 协议继承 SPDM 的时序规范,包括用于确定响应方必须响应需要加密处理的消息的时序参数 CT。

表 8 GET_TDISP_CAPABILITIES

偏移量字段大小(字节)说明
负载(所有字段均为小端序)
16TSM_CAPS4
11.3.7 TDISP_CAPABILITIES

响应方支持的能力。

表 9 TDISP_CAPABILITIES

偏移量字段大小(字节)说明
负载(所有字段均为小端序)
16DSM_CAPS4DSM 能力标志,位 31:0——保留
20REQ_MSGS_SUPPORTED16位掩码,指示设备支持的每种请求消息类型,位索引对应表 3 中定义的消息码减去 80h
36LOCK_INTERFACE_FLAGS_SUPPORTED2位掩码,指示设备支持的“锁定接口标志”,位索引对应表 10 中的“FLAGS”字段定义。不支持特定标志,表示软件不得假设设备在相关能力方面有特定行为,除非通过其他方式具备设备特定知识
38-3保留
41DEV_ADDR_WIDTH1设备报告其支持的地址位数,例如,此字段值为 52 表示支持位 51:0
42NUM_REQ_THIS1DSM 允许的针对此 TDI 的未完成请求数量
43NUM_REQ_ALL1DSM 允许的针对其管理的所有 TDI 的未完成请求数量
11.3.8 LOCK_INTERFACE_REQUEST

“LOCK_INTERFACE_REQUEST”用于将 TDI 转换至 CONFIG_LOCKED 状态,但需 DSM 确认设备(包括功能 0 的元素和 TDI 本身)的配置和状态均符合要求。

若检测到以下任何错误,设备必须拒绝请求:

  • 请求中指定的接口 ID(Interface ID)不由该设备承载;

  • TDI 未处于 CONFIG_UNLOCKED 状态;

  • 对于要求使用 IDE 的 TDI:

    • 默认流与指示的流 ID 不匹配;

    • 默认流的所有子流未配置 IDE 密钥;

    • 默认流的所有 IDE 密钥未通过接收“LOCK_INTERFACE_REQUEST”的 SPDM 会话配置;

    • 设备中的多个 IDE 配置寄存器已配置为默认流;

    • 默认流与 TC0 以外的传输类别(TC)相关联;

  • 幻影功能(Phantom Functions)已启用;

  • 设备 PF BAR(基地址寄存器)配置了重叠地址;

  • 若支持扩展 ROM 基地址(Expansion ROM Base Address),其配置与某一 BAR 重叠;

  • 可调整大小 BAR(Resizable BAR)控制寄存器编程了不支持的 BAR 大小;

  • VF BAR 配置的地址与其他 VF BAR、PF BAR 或扩展 ROM BAR 重叠;

  • SR-IOV 能力的系统页面大小寄存器中配置了不支持的系统页面大小;

  • 若支持并启用了 LN 请求方能力(LN Requester Capability,在 PCIe 6.0 版本中已弃用),其配置的缓存行大小与“LOCK_INTERFACE_REQUEST”中指定的系统缓存行大小不匹配,或配置为设备不支持的值;

  • 若支持并启用了 TPH 请求方扩展能力(TPH Requester Extended Capability),其选择的 ST 模式与承载 TDI 的功能支持的模式不对应;

  • 设备或 TDI 配置中其他由设备确定的错误。

“LOCK_INTERFACE_REQUEST”将以下参数绑定并配置到 TDI 中:

  • MMIO_REPORTING_OFFSET:为避免向 TVM 泄露物理地址,TSM 指定“MMIO_REPORTING_OFFSET”,应用于该 TDI 生成的所有后续“DEVICE_INTERFACE_REPORT”。“MMIO_REPORTING_OFFSET”是 64 位有符号(二进制补码)值,必须添加到 TDI 报告的所有 MMIO 物理地址中。为保持主机特定的页面对齐,TSM 可将“MMIO_REPORTING_OFFSET”的相应低位设为 0;TSM 必须提供不会导致溢出/下溢的偏移量。

  • NO_FW_UPDATE:置位时,表示当此 TDI 处于 CONFIG_LOCKED 或 RUN 状态时,设备不得接受固件更新。此选项允许某些 TVM 在开始使用 TDI 后,选择不允许设备进一步更新固件。若要执行固件更新,VMM 必须将所有使用“NO_FW_UPDATE=1”锁定的 TDI 从 TVM 中分离,并将其转换至 CONFIG_UNLOCKED 状态。

  • 系统缓存行大小。

  • 是否必须锁定承载 TDI 的功能中的 MSI-X 表和 PBA:即使未指示锁定,TDI 也可锁定 MSI-X 表和 PBA;若未锁定 MSI-X 表和 PBA,则不得在“DEVICE_INTERFACE_REPORT”中报告它们;若已锁定 MSI-X 表和 PBA,则必须拒绝未置位 T 位的访问 MSI-X 表和 PBA 的事务。

  • BIND_P2P:置位时,表示后续可通过“BIND_P2P_STREAM_REQUEST”消息启用直接对等(P2P,设备/设备对等)支持,且请求中指定了有效的 P2P 地址掩码;未置位时,表示不允许或未为该 TDI 启用直接对等(P2P)。

  • ALL_REQUEST_REDIRECT:置位时,表示 TDI 必须将所有 ATS 转换请求(ATranslated Requests)重定向到上游的根复合体,若已配置默认选择性 IDE 流,则使用该流执行访问检查。这包括 TDI 对基于转换地址(Translated Address)的 TDI 内部本地资源或设备其他资源的访问。

成功处理请求后,设备返回“LOCK_INTERFACE_RESPONSE”消息。

表 10 LOCK_INTERFACE_REQUEST

偏移量字段大小(字节)说明
负载(所有字段均为小端序)
16FLAGS2位 0——NO_FW_UPDATE:置 1 时,表示处于 CONFIG_LOCKED 或 RUN 状态时不允许设备固件更新;置 0 时,表示这些状态下允许固件更新。
位 2——LOCK_MSIX:锁定 MSI-X 表和 PBA。
位 3——BIND_P2P:置 1 时,表示后续可通过“BIND_P2P_STREAM_REQUEST”消息启用直接对等(P2P)支持,且请求中指定了有效的 P2P 地址掩码;置 0 时,表示不允许或未为该 TDI 启用直接对等(P2P)。
位 4——ALL_REQUEST_REDIRECT:TDI 必须将所有 ATS 转换请求重定向到上游的根复合体,以执行访问检查。
位 15:5——保留
18默认流的流 ID(Stream ID for Default Stream)1指示配置为 IDE 默认流的流 ID
19-1保留
20MMIO_REPORTING_OFFSET8所有“DEVICE_INTERFACE_REPORT”中报告的 MMIO 范围,均在物理地址上添加此偏移量
28BIND_P2P_ADDRESS_MASK8应用于 TDI 使用“BIND_P2P_STREAM_REQUEST”流发起的对等事务的目标地址的掩码(用于清除地址中嵌入的任何元数据信息)。在使用选择性 IDE 地址关联机制前,必须应用此掩码。此掩码不适用于或不应用于绑定到根复合体的请求
11.3.9 LOCK_INTERFACE_RESPONSE

“LOCK_INTERFACE_RESPONSE”在成功处理“LOCK_INTERFACE_REQUEST”且设备已将 TDI 转换至 CONFIG_LOCKED 状态时返回。该响应消息还提供“START_INTERFACE_NONCE”(随机数),此随机数在 TDI 锁定时由设备生成;当 TDI 从 CONFIG_LOCKED 状态转换至 CONFIG_UNLOCKED 或 ERROR 状态时,必须销毁此随机数。有关此随机数的其他规则,参见 11.3.14 节。

生成“LOCK_INTERFACE_RESPONSE”,意味着设备已成功完成以下操作:

  • 中止“LOCK_INTERFACE_REQUEST”接收前,TDI 的所有在途和已接受工作;

  • 完成或中止“LOCK_INTERFACE_REQUEST”接收前,TDI 的所有 DMA(直接内存访问);

  • 若承载 TDI 的功能支持地址转换服务(ATS),则“LOCK_INTERFACE_REQUEST”接收前生成的所有 TDI 的 ATS 请求已完成或中止;设备必须使承载 TDI 的功能的请求方 ID(Requester ID)在 ATC(地址转换缓存)中缓存的转换失效;

  • 若承载 TDI 的功能支持页面请求接口服务(PRI),则“LOCK_INTERFACE_REQUEST”接收前生成的所有 TDI 的页面请求已收到响应,或 TDI 将丢弃未完成页面请求的页面响应;

  • DSM 在锁定 TDI 时,已成功分配并分配给 TDI 所需的其他私有资源;

  • DSM 已在设备端执行必要操作,以锁定 TDI 配置和默认流的 IDE 配置寄存器;DSM 已启用机制,以跟踪 TDI 配置和默认流的 IDE 配置寄存器的变更。

设备可出于特定于实现的原因,对“LOCK_INTERFACE_REQUEST”返回“INVALID_DEVICE_CONFIGURATION”(无效设备配置)。

表 11 LOCK_INTERFACE_RESPONSE

偏移量字段大小(字节)说明
负载(所有字段均为小端序)
16START_INTERFACE_NONCE32设备生成的随机数,包含在“START_INTERFACE_REQUEST”消息中

以下表定义了错误码和对应条件:

表 12 LOCK_INTERFACE_REQUEST 错误响应码

错误码说明
INVALID_REQUEST设备支持 IDE 能力,且满足以下条件之一:
默认流的所有子流未配置密钥;
默认流的密钥未通过接收“LOCK_INTERFACE_REQUEST”的 SPDM 会话配置
INSUFFICIENT_ENTROPY设备无法生成随机数
INVALID_INTERFACE_STATETDI 未处于 CONFIG_UNLOCKED 状态
INVALID_DEVICE_CONFIGURATION因设备配置无效/不支持,导致 TDI 锁定失败
11.3.10 GET_DEVICE_INTERFACE_REPORT

“GET_DEVICE_INTERFACE_REPORT”用于向设备请求“DEVICE_INTERFACE_REPORT”。在某些情况下,“DEVICE_INTERFACE_REPORT”可能大于请求方可一次接收的大小,因此为请求方提供了请求发送整个“DEVICE_INTERFACE_REPORT”中特定部分的方式。

若检测到以下任何错误,设备必须拒绝请求:

  • 请求中的接口 ID(Interface ID)不由该设备承载;

  • TDI 未处于 CONFIG_LOCKED 或 RUN 状态;

  • 指定的偏移量(Offset)无效。

表 13 GET_DEVICE_INTERFACE_REPORT

偏移量字段大小(字节)说明

11.3.10 GET_DEVICE_INTERFACE_REPORT(续)

偏移量字段大小(字节)说明
负载(所有字段均为小端序)---
16OFFSET2从报告起始位置到读取请求消息开始位置的字节偏移量。响应方必须从该偏移量开始发送报告。对于第一次 GET_DEVICE_INTERFACE_REPORT 请求,请求方必须将此字段设为 0;对于非第一次请求,偏移量为所有之前 DEVICE_INTERFACE_REPORT 响应中 PORTION_LENGTH 值的总和。
18LENGTH2要在对应响应中返回的报告字节长度,为无符号 16 位整数。此值为以下两个值中的较小者:
1. 请求方接收响应报告的内部缓冲区容量;
2. 前一个 DEVICE_INTERFACE_REPORT 响应中的 REMAINDER_LENGTH。
对于第一次 GET_DEVICE_INTERFACE_REPORT 请求,请求方必须使用其接收缓冲区的容量;若偏移量=0且长度=FFFFh,表示请求方请求获取完整报告。若响应方缓冲区长度有限,允许返回小于请求长度的内容。
11.3.11 DEVICE_INTERFACE_REPORT

表 14 DEVICE_INTERFACE_REPORT

偏移量字段大小(字节)说明
负载(所有字段均为小端序)---
16PORTION_LENGTH2此部分 TDI 报告的字节数,必须小于或等于请求中接收的 LENGTH 值。例如,因响应方内部缓冲区限制,响应方可将此字段设为小于请求中 LENGTH 值的数值。
18REMAINDER_LENGTH2当前响应后尚未发送的 TDI 报告字节数。对于最后一次响应,此字段必须设为 0,以向请求方指示已发送完整 TDI 报告。
20REPORT_BYTESPORTION_LENGTH请求的 TDI 报告内容

TDI 报告结构如下:

表 15 TDI 报告结构

偏移量字段大小(字节)说明
0INTERFACE_INFO2位 0:置 1 时,表示处于 CONFIG_LOCKED 或 RUN 状态时不允许设备固件更新;置 0 时,表示这些状态下允许固件更新。
位 1:TDI 生成无 PASID(进程地址空间 ID)的 DMA 请求。
位 2:TDI 生成带 PASID 的 DMA 请求。
位 3:TDI 支持并启用 ATS(地址转换服务)。
位 4:TDI 支持并启用 PRS(页面请求服务)。
位 15:5:保留。
2-2预留用于未来扩展。
4MSI_X_MESSAGE_CONTROL2MSI-X 能力消息控制寄存器状态。若满足以下任一条件,必须置 0:
1. 不支持 MSI-X 能力;
2. 未锁定 MSI-X 表。
6LNR_CONTROL2来自 LN 请求方扩展能力的 LNR 控制寄存器。若不支持 LNR 能力,必须置 0(LN 在 PCIe 6.0 版本中已弃用)。
8TPH_CONTROL4来自 TPH 请求方扩展能力的 TPH 请求方控制寄存器。若满足以下任一条件,必须置 0:
1. 不支持 TPH 能力;
2. 未锁定 MSI-X 表。
12MMIO_RANGE_COUNT (N)4报告中的 MMIO 范围数量。
16MMIO_RANGEN×16每个 TDI 的 MMIO 范围均添加 MMIO 报告偏移量后报告,基地址和大小以 4K 页为单位:
8 字节:添加偏移量后的第一个 4K 页;
4 字节:此范围中的 4K 页数;
4 字节:范围属性:
- 位 0:MSI-X 表——若该范围映射 MSI-X 表,仅在 LOCK_INTERFACE_REQUEST 锁定后才报告;
- 位 1:MSI-X PBA(待处理中断数组)——若该范围映射 MSI-X PBA,仅在 LOCK_INTERFACE_REQUEST 锁定后才报告;
- 位 3:IS_MEM_ATTR_UPDATABLE——若可通过 SET_MMIO_ATTRIBUTE_REQUEST 更新此范围的属性,必须置 1;
- 位 15:4:保留;
- 位 31:16:范围 ID——指定范围的设备特定标识符,可用于将一个或多个 MMIO 范围逻辑分组为更大范围。
16 + N×16DEVICE_SPECIFIC_INFO_LEN (L)4设备特定信息的字节数。
16 + N×16 + 4DEVICE_SPECIFIC_INFOL设备特定信息。

TDI 生成 DMA 请求的方式可能有以下三种:1. 所有 DMA 请求均无 PASID;2. 所有 DMA 请求均带 PASID;3. 部分 DMA 请求带 PASID、部分不带。

范围 ID 用于将报告中的范围逻辑分组为逻辑组。

必须按 BAR 编号升序报告通过 BAR 分配的 MMIO 范围,即第一个范围对应第一个 BAR,依此类推。范围 ID 报告 BAR 等效指示符(BEI),范围 ID 的 0-7 值预留用于指示 BEI;对于与 PCIe BAR 关联的范围,设备必须报告 BAR 等效指示符(BEI)。

报告 TDI 的 MMIO 范围时,必须按 TDI MMIO 范围的配置逻辑顺序报告,即第一个报告的范围对应 TDI 中的第一个页面范围,依此类推。

设备可在报告中向 TVM 包含额外的设备特定信息,这些信息可用于报告 TDI 的配置和/或枚举 TDI 的能力。此类设备特定信息示例包括:

  • 网络设备可包含接收端缩放(RSS)相关信息,如 RSS 哈希及与虚拟站点接口(VSI)队列的映射等;

  • NVMe 设备可包含相关命名空间信息、命名空间到命令队列对的映射等;

  • 加速器可报告支持的算法、队列深度等能力。

下图展示了响应方无法在第一次响应中返回请求方所需全部数据时,响应方的高级请求-响应消息流:
在这里插入图片描述

图 11-7 DSM 无法返回完整长度报告的示例流程

(注:图中展示了 TVM、TSM、DSM 三者的交互:TVM 发起获取设备接口报告的请求,TSM 向 DSM 发送 GET_DEVICE_INTERFACE_REPORT(偏移量 0,长度 0x1000),DSM 因设备缓冲区大小限制(0x800),首次返回 PORTION_LENGTH=0x800、REMAINDER_LENGTH=0x200 的报告;TSM 随后发送 GET_DEVICE_INTERFACE_REPORT(偏移量 0x800,长度 0x200),DSM 返回 PORTION_LENGTH=0x200、REMAINDER_LENGTH=0 的报告;最终 TSM 将完整报告传递给 TVM,TVM 验证 MMIO 映射并反馈映射状态。)

以下表定义了错误码和对应条件:

表 16 GET_DEVICE_INTERFACE_REPORT 错误响应码

错误码说明
INVALID_REQUEST偏移量无效。
INVALID_INTERFACE_STATETDI 未处于 CONFIG_LOCKED 状态。
11.3.12 GET_DEVICE_INTERFACE_STATE

GET_DEVICE_INTERFACE_STATE 用于向设备请求 DEVICE_INTERFACE_STATE(TDI 状态)。

若检测到以下错误,设备必须拒绝请求:

  • 请求中的接口 ID(Interface ID)不由该设备承载。
11.3.13 DEVICE_INTERFACE_STATE

表 17 DEVICE_INTERFACE_STATE

偏移量字段大小(字节)说明
负载(所有字段均为小端序)---
16TDI_STATE1TDI 状态:
0——CONFIG_UNLOCKED(配置未锁定);
1——CONFIG_LOCKED(配置锁定);
2——RUN(运行);
3——ERROR(错误);
其他值:保留。
11.3.14 START_INTERFACE_REQUEST

START_INTERFACE_REQUEST 包含 TDI 的接口 ID,用于将 TDI 转换至 RUN 状态(在此状态下由 TVM 管理和操作)。此请求应由 TSM 根据 TVM 的请求生成。

若检测到以下任何错误,设备必须拒绝请求:

  • 请求中的接口 ID 不由该设备承载;

  • 请求中的 START_INTERFACE_NONCE(随机数)无效,即与设备在 LOCK_INTERFACE_RESPONSE 中生成的随机数不匹配;

  • TDI 未处于 CONFIG_LOCKED 状态。

若未检测到错误,设备准备将相关 TDI 转换至 RUN 状态。将 TDI 转换至 RUN 状态可能涉及设备端操作(如启用设备端内存加密等)。在将 TDI 转换至 RUN 状态前,设备必须使 START_INTERFACE_NONCE 失效,确保此随机数无法再次使用。

表 18 START_INTERFACE_REQUEST

偏移量字段大小(字节)说明
负载(所有字段均为小端序)---
16START_INTERFACE_NONCE32设备生成的消息随机数(来自 LOCK_INTERFACE_RESPONSE)。
11.3.15 START_INTERFACE_RESPONSE

以下表定义了错误码和对应条件:

表 19 START_INTERFACE_REQUEST 错误响应码

错误码说明
INVALID_NONCESTART_INTERFACE_NONCE 不匹配。
INVALID_INTERFACE_STATETDI 未处于 CONFIG_LOCKED 状态。
11.3.16 STOP_INTERFACE_REQUEST

STOP_INTERFACE_REQUEST 包含 TDI 的接口 ID。

若检测到以下错误,设备必须拒绝请求:

  • 请求中的接口 ID 不由该设备承载。

响应 STOP_INTERFACE_REQUEST,必须执行以下操作:

  • 中止 TDI 正在执行的所有在途和已接受操作;

  • 等待已中止操作的未完成响应;

  • 中止或完成 TDI 的所有 DMA 读写操作;

  • 生成 TDI 的所有中断;

  • 若承载 TDI 的功能支持地址转换服务(ATS),则完成或中止 TDI 的所有 ATS 请求,并使设备中缓存的、由该 TDI 生成的 ATS 请求相关转换失效;

  • 若承载 TDI 的功能支持页面请求接口服务(PRI),则 TDI 不得再生成页面请求,且要么已收到所有由 TDI 生成的页面请求的响应,要么 TDI 将丢弃未完成页面请求的响应;

  • 清理设备的内部状态,移除与 TDI 关联的机密信息,确保这些机密信息无法访问;

  • 回收并清理分配给 TDI 的私有资源(如设备附加内存的内存加密密钥等)。

完成上述操作后,设备必须生成 STOP_INTERFACE_RESPONSE(停止接口响应)。

11.3.17 STOP_INTERFACE_RESPONSE

无特定于请求的响应定义。

11.3.18 BIND_P2P_STREAM_REQUEST

TDI 允许支持两个设备之间端到端安全的对等(P2P)事务。此类设备必须支持配置一个或多个选择性 IDE 流,确保选择性 IDE 流配置寄存器提供对等设备的地址和请求方 ID(RID)范围。仅当设备支持地址转换服务(ATS)且已启用该能力时,才可使用此类对等 IDE 流。

BIND_P2P_STREAM_REQUEST 用于将此类对等流 ID 绑定到 TDI。若满足以下任何条件,设备必须拒绝请求:

  • 请求中的接口 ID 不由该设备承载;

  • TDI 不支持绑定对等流;

  • TDI 未处于 RUN 状态;

  • 指定的流 ID 的所有子流未配置 IDE 密钥;

  • 指定流 ID 的所有 IDE 密钥未通过接收 LOCK_INTERFACE_REQUEST 的 SPDM 会话配置;

  • 多个 IDE 配置寄存器已编程相同的流 ID;

  • 此流的 IDE 配置寄存器已配置为默认流;

  • 此流的 IDE 配置寄存器的地址和/或 RID 关联寄存器与其他 IDE 配置寄存器重叠。

响应请求时,DSM 需在设备端执行必要操作,以锁定指定流 ID 的 IDE 配置,并启用机制跟踪 IDE 配置寄存器的变更。

DSM 需通过设备特定机制确保事务排序的正确性(例如,若之前的事务通过 LOCK_INTERFACE_REQUEST 指定的默认流路由,则 TDI 需在开始使用此请求指定的对等流前实现隔离机制)。

处理请求后,设备生成 BIND_P2P_STREAM_RESPONSE(绑定对等流响应)。

当 TDI 生成事务时,若事务的地址或请求方 ID(如适用)与某一 IDE 配置寄存器匹配,且配置的流 ID 是绑定到该 TDI 的对等流之一,则设备使用该对等流处理事务;若事务不匹配任何对等 IDE 流,则使用通过 LOCK_INTERFACE_REQUEST 绑定的默认流处理事务。

所有 ATS 请求,以及目标地址未事先从根复合体中的转换代理(TA)获取转换结果的请求,必须使用锁定 TDI 时绑定的默认流。

表 20 BIND_P2P_STREAM_REQUEST

偏移量字段大小(字节)说明
负载---
16P2P_STREAM_ID1要绑定到该 TDI 的对等(P2P)流 ID。
11.3.19 BIND_P2P_STREAM_RESPONSE

以下表定义了错误码和对应条件:

表 21 BIND_P2P_STREAM_REQUEST 错误响应码

错误码说明
INVALID_REQUESTP2P_STREAM_ID 无效;
对等流的所有子流未配置密钥;
通过 P2P_STREAM_ID 标识的流的密钥,未通过接收 LOCK_INTERFACE_REQUEST 的 SPDM 会话配置;
配置该 P2P_STREAM_ID 的 IDE 寄存器被标记为默认流;
多个 IDE 寄存器配置了相同的 P2P_STREAM_ID;
为该 P2P_STREAM_ID 配置的 IDE 寄存器与其他有效 IDE 寄存器重叠。
INVALID_INTERFACE_STATETDI 未处于 RUN 状态。
11.3.20 UNBIND_P2P_STREAM_REQUEST

UNBIND_P2P_STREAM_REQUEST 用于将之前绑定到 TDI 的对等流 ID 从 TDI 解绑。若满足以下任何条件,设备必须拒绝请求:

  • 请求中的接口 ID 不由该设备承载;

  • TDI 不支持绑定对等流;

  • TDI 未处于 RUN 状态;

  • 指定的流 ID 未事先绑定到该 TDI。

处理请求后,设备生成 UNBIND_P2P_STREAM_RESPONSE(解绑对等流响应)。生成 UNBIND_P2P_STREAM_RESPONSE 意味着设备已成功完成以下操作:

  • 中止或完成 TDI 使用指定对等流的所有 DMA 读写操作;

  • 解除对此流的 IDE 配置寄存器的锁定,确保重新编程 IDE 寄存器不会影响 TDI 的安全性;

  • 若设备支持在解绑后继续对等操作,则需通过设备特定机制确保事务排序的正确性(例如,若之前的事务通过此对等流路由,则 TDI 需在开始使用默认流前实现隔离机制)。

表 22 UNBIND_P2P_STREAM_REQUEST

偏移量字段大小(字节)说明
负载---
16P2P_STREAM_ID1要从该 TDI 解绑的对等(P2P)流 ID。
11.3.21 UNBIND_P2P_STREAM_RESPONSE

以下表定义了错误码和对应条件:

表 23 UNBIND_P2P_STREAM_REQUEST 错误响应码

错误码说明
INVALID_REQUESTTDI 不支持绑定对等流;
P2P_STREAM_ID 无效;
P2P_STREAM_ID 未事先绑定到该 TDI。
INVALID_INTERFACE_STATETDI 未处于 RUN 状态。
11.3.22 SET_MMIO_ATTRIBUTE_REQUEST

SET_MMIO_ATTRIBUTE_REQUEST 允许 TVM 更新 DEVICE_INTERFACE_REPORT 中报告的一个或多个 MMIO 范围的属性。TDI 中支持属性更新的 MMIO 范围由设备特定规则定义。

若满足以下任何条件,设备必须拒绝请求:

  • 请求中的接口 ID 不由该设备承载;

  • TDI 不支持可更新的 MMIO 属性;

  • TDI 不支持对请求的 MMIO 范围更新属性;

  • TDI 不支持对请求的 MMIO 范围设置指定属性;

  • TDI 不支持属性的指定值;

  • TDI 未处于 RUN 状态;

  • 请求中指定的 MMIO 范围与 TDI 无关联。

请求失败不会导致 TDI 状态变更。处理请求后,设备生成 SET_MMIO_ATTRIBUTE_RESPONSE(设置 MMIO 属性响应)。

将 IS_NON_TEE_MEM 属性更新为 1 时,允许将请求的 MMIO 范围与 TVM 信任边界外的实体共享。成功更新为 1 后,可通过 T 位为 0 或 1 的请求,或通过非 IDE 请求访问该 MMIO 范围。在请求处理期间,设备可继续拒绝 T 位为 0 且访问该 MMIO 范围的请求。

将 IS_NON_TEE_MEM 属性更新为 0 时,禁止将该 MMIO 范围与 TVM 信任边界外的实体共享。成功更新为 0 后,仅可通过 T 位为 1 的请求访问该 MMIO 范围,必须拒绝 T 位为 0 的请求。在请求处理期间,设备允许通过 T 位为 0 的请求访问该范围。

生成 SET_MMIO_ATTRIBUTE_RESPONSE 意味着设备已成功完成指定 MMIO 范围的属性更新,且更新后的属性对该 MMIO 范围的所有后续访问生效。

表 24 SET_MMIO_ATTRIBUTE_REQUEST

偏移量字段大小(字节)说明
负载(所有字段均为小端序)---
16MMIO_RANGE16要更新属性的 MMIO 范围的基地址和大小:
- 位 2:IS_NON_TEE_MEM——若该范围为非 TEE 内存,置 1;
- 位 15:4:保留;
- 位 31:16:范围 ID——指定范围的设备特定标识符。
11.3.23 SET_MMIO_ATTRIBUTE_RESPONSE

以下表定义了错误码和对应条件:

表 25 SET_MMIO_ATTRIBUTE_REQUEST 错误响应码

错误码说明
INVALID_INTERFACE_STATETDI 未处于 RUN 状态。
11.3.24 TDISP_ERROR

设备可使用 TDISP_ERROR 完成所有发送给它的请求。

表 26 TDISP_ERROR

偏移量字段大小(字节)说明
负载(所有字段均为小端序)---
16ERROR_CODE4错误码。
20ERROR_DATA4错误数据。
24EXTENDED_ERROR_DATA可变扩展错误数据。

表 27 错误码与错误数据

错误码数值(十六进制)说明错误数据扩展错误数据
保留(Reserved)0000保留保留无
无效请求(INVALID_REQUEST)0001请求的一个或多个字段无效保留无
忙碌(BUSY)0003响应方收到请求消息但决定忽略,若后续重新发送请求,响应方可能能够处理保留无
无效接口状态(INVALID_INTERFACE_STATE)0004响应方在错误状态下收到请求,或收到意外请求(例如,在 LOCK_INTERFACE_REQUEST 前发送 GET_DEVICE_INTERFACE_REPORT,或在多个 GET_DEVICE_INTERFACE_REPORT 之间发送其他命令)保留无
未指定错误(UNSPECIFIED)0005发生未指定的错误保留无
不支持的请求(UNSUPPORTED_REQUEST)0007请求码不支持请求码无
版本不匹配(VERSION_MISMATCH)0041版本不支持保留无
供应商特定错误(VENDOR_SPECIFIC_ERROR)00FF供应商定义的错误扩展错误数据长度参见供应商定义错误的扩展错误数据格式要求
无效接口(INVALID_INTERFACE)0101INTERFACE_ID 不存在保留无
无效随机数(INVALID_NONCE)0102收到的随机数与预期不匹配保留无
熵不足(INSUFFICIENT_ENTROPY)0103响应方无法生成随机数保留无
无效设备配置(INVALID_DEVICE_CONFIGURATION)0104设备配置无效/不支持保留无

以下表定义了供应商定义的 TDISP_ERROR 响应消息中 EXTENDED_ERROR_DATA(扩展错误数据)的格式:

表 28 EXTENDED_ERROR_DATA

字段大小(字节)说明
0REGISTRY_ID1
1VENDOR_ID_LEN1
2VENDOR_IDVENDOR_ID_LEN
2 + VENDOR_ID_LENVENDOR_ERR_DATA可变
11.3.25 VDM_REQUEST

以下表定义了 VDM_REQUEST(供应商定义消息请求)的格式:

表 29 VDM_REQUEST

偏移量字段大小(字节)说明
0REGISTRY_ID1分配 VENDOR_ID 的注册机构 ID:
00h——PCI-SIG 分配的供应商 ID;
01h——CXL 分配的供应商 ID。
1VENDOR_ID_LEN1VENDOR_ID 字段的长度。
2VENDOR_IDVENDOR_ID_LEN由 REGISTRY_ID 标识的注册机构分配的 VENDOR_ID。
2 + VENDOR_ID_LENVENDOR_DATA可变供应商定义的数据。
11.3.26 VDM_RESPONSE

以下表定义了 VDM_RESPONSE(供应商定义消息响应)的格式:

表 30 VDM_RESPONSE

偏移量字段大小(字节)说明
0REGISTRY_ID1分配 VENDOR_ID 的注册机构 ID:
00h——PCI-SIG 分配的供应商 ID;
01h——CXL 分配的供应商 ID。
1VENDOR_ID_LEN1VENDOR_ID 字段的长度。
2VENDOR_IDVENDOR_ID_LEN由 REGISTRY_ID 标识的注册机构分配的 VENDOR_ID。
2 + VENDOR_ID_LENVENDOR_DATA可变供应商定义的数据。

11.4 设备安全要求

11.4.1 设备身份与认证

支持 TEE-I/O 的设备必须实现 [SPDM](安全协议和数据模型),将其作为与主机通信的设备安全协议。设备必须使用 SPDM 协议报告设备身份并支持认证,且需满足 SPDM 规范中定义的安全属性。

建议设备实现可信计算组(TCG)指定的设备标识符组合引擎(DICE)架构。在这种情况下,必须在 SPDM 协议中返回 DICE 证书,用于提供设备身份并支持认证。

11.4.2 固件与配置测量

支持 TEE-I/O 的设备必须实现 [SPDM],向 TSM 报告设备测量信息。TEE-I/O 设备可向主机报告基于哈希的测量值和/或安全版本号(SVN)。

建议设备实现 TCG DICE。在这种情况下,基于哈希的设备测量值和/或 SVN 也必须包含在 DICE TCB 信息结构中;SPDM 测量响应和 DICE TCB 信息中报告的信息必须一致。

设备允许支持可变固件更新。在这种情况下,建议设备遵循已确立的行业固件弹性指南(如 NIST SP 800-193),确保新固件的安全性不低于旧固件。

设备允许支持无需重置的运行时更新。此类能力必须通过 INTERFACE_INFO 报告,且可通过 NO_FW_UPDATE 禁止。若需维持活跃的 TDI,运行时更新镜像的 SVN 必须大于或等于当前版本。设备必须报告 SPDM MEAS_FRESH_CAP(测量新鲜度能力),以指示设备是否具备报告新鲜测量值(而非上次设备重置时计算的旧测量值)的能力。

若 DICE 设备支持运行时更新,必须仍满足 DICE 规范中定义的安全属性(如 DICE 证书创建)。若存在处于 CONFIG_LOCKED 或 RUN 状态的活跃 TDI,设备必须拒绝降低 SVN 的操作;或者,若设备具备在降级前以可信方式安全清除所有 TVM 数据的能力,可将处于 CONFIG_LOCKED 或 RUN 状态的接口转换至 ERROR 状态、终止用于 TEE-I/O 的 IDE 流、终止与 TSM 的 SPDM 会话,之后再执行固件降级。

若设备在存在处于 CONFIG_LOCKED 或 RUN 状态的 TDI 时不支持运行时更新,必须通过终止用于 TEE-I/O 的 IDE 流、终止 TSM 与 DSM 之间的 SPDM 会话、将相关 TDI 转换至 ERROR 状态,来处理强制更新。

11.4.3 互连安全

支持 TEE-I/O 的设备必须支持完整性与数据加密(IDE),以保护设备与根复合体之间互连上的事务。设备必须支持根复合体与设备之间的选择性 IDE 流;对于 RCiEP(根复合体集成端点),可能无需使用 IDE 保护事务。

设备之间的对等链路必须受到保护,以避免机密性和完整性损失;对等链路必须使用 IDE 确保通信安全。其他类型的互连必须通过互连特定扩展进行保护,确保其提供的安全性与 IDE 概述的威胁模型要求相当。

每个 IDE 子流的对称流加密密钥和初始向量(IV)均为机密信息,泄露这些信息将破坏方案的安全性。设备必须实现足够的安全措施,防止加密密钥在存储和使用过程中泄露;不得以明文形式向设备外暴露流加密密钥;不得允许通过不可信机制修改流加密密钥或 IV。

当绑定到接口的 IDE 流转换至不安全状态时,支持 TEE-I/O 的设备必须将处于 CONFIG_LOCKED 或 RUN 状态的接口转换至 ERROR 状态;设备必须实现适当的机制,防止数据在转换至不安全状态后继续传播。

若处于 CONFIG_LOCKED 或 RUN 状态的接口收到带有 UR(未支持请求)/CA(配置访问)的完成包,或完成包超时(恢复重试后),表明处理未发布请求时发生不可纠正错误(如 IOMMU 转换表损坏等)。若错误无法恢复,设备必须将收到 UR/CA 的接口转换至 ERROR 状态,以停止错误的传播和影响。

11.4.4 设备附加内存

部分设备会实现设备附加内存,供设备内部逻辑用于存储 TVM 数据。设备必须确保存储在这类内存中的 TVM 数据的机密性,不得将 TVM 数据以明文形式暴露在设备外或泄露给 TVM 可信计算基(TCB)外的实体;应尽可能确保 TVM 数据的密文也不暴露在设备外。设备还可额外为 TVM 数据提供完整性保护。

实施说明:设备附加内存安全

部分设备可能通过内存加密机制确保存储在这类内存中的 TVM 数据的机密性,还可能额外为内存内容提供完整性保护。这类设备中与设备附加内存相关的内存加密配置及其他配置,由 DSM 管理;TSM 依赖 DSM 确保这些配置的安全性。

必须在 DSM 收到该设备承载的设备接口的第一个 LOCK_INTERFACE_REQUEST 前,完成内存配置的安全保护、内存加密的建立以及所有相关安全检查。若内存配置无法满足 TVM 安全要求,则不得将设备接口转换至 CONFIG_LOCKED 状态。

11.4.5 TDI 安全

支持 TEE-I/O 的设备必须支持 [安全 SPDM],以在 TSM 与 DSM 之间建立安全通信会话;设备必须支持 TDISP 中的 TDI 状态和设备接口管理协议,用于管理分配给 TVM 或从 TVM 分离的设备安全状态。

绑定到 TDI 的 IDE 流的所有子流,必须通过用于锁定接口的同一 SPDM 会话进行编程;尝试通过不同 SPDM 会话为子流配置 IDE 密钥属于错误,必须拒绝;仅允许通过用于建立初始 IDE 密钥的 SPDM 会话刷新 IDE 密钥。

处于 RUN 状态的 TDI,若设备模型支持此类通信,可通过对等选择性 IDE 流与其他 TDI 传输/接收事务;仅当对等 IDE 流的 IDE 密钥也通过用于将 TDI 转换至 CONFIG_LOCKED 状态的同一 SPDM 会话配置时,才可使用这些对等 IDE 流进行通信。

当用于编程 IDE 流密钥的 SPDM 会话进入会话终止阶段时,通过该 SPDM 会话配置密钥的所有 IDE 流必须转换至不安全状态,且通过该 SPDM 会话转换至 CONFIG_LOCKED 状态的所有 TDI 必须转换至 ERROR 状态。

当 IDE 流转换至不安全状态时,所有绑定到该 IDE 流且处于 CONFIG_LOCKED/RUN 状态的 TDI 必须转换至 ERROR 状态。

支持 TEE-I/O 的设备必须确保分配给 TVM 的 TDI 相关配置和数据的机密性与完整性;设备必须实现适当的机制,防止这些配置和数据被其他 TDI(包括设备的物理功能(PF))泄露或篡改。

设备可将通过物理功能(PF)或设备管理队列提供的管理功能视为不可信。通常,由 VMM 管理的此类管理接口,会被将 VMM 纳入信任边界的虚拟机(如虚拟功能或 TDI)信任;但由于 TVM 可能不将 VMM 纳入信任边界,VMM 执行的管理操作需由 DSM 进行介导,确保这些操作不会危及 TVM 数据、链路加密密钥、SPDM 会话密钥及其他对方案安全性至关重要的机密信息的机密性或完整性。

仅影响服务质量(QoS)或性能特性、但不会危及接口功能正确性和安全性的管理功能(如 QoS 配置等),在 TDI 处于 CONFIG_LOCKED 或 RUN 状态时可允许执行。

建议支持 TEE-I/O 的设备在设计时,尽量避免或减少主机驱动程序对 TDI 特定配置或控制操作的干预(若这些操作被恶意执行,可能危及 TVM 数据的机密性或完整性)。仅影响 TDI 服务质量或性能特性、但不影响接口功能正确性和安全性的操作,可由主机驱动程序代表 TVM 执行;主机驱动程序可能不在分配给 TVM 的 TDI 的信任边界内,且不得信任其提供 TVM 操作的软件模拟。

修改设备配置(如重新编程物理功能或虚拟功能的 BAR、修改 TDI 配置等),可能被用于暂时丢弃 TVM 发起的事务,或导致 TVM 机密数据泄露(例如,将事务重定向到其他虚拟功能的寄存器)。此类配置元素可能位于物理功能的配置空间、虚拟功能的配置空间、物理功能或虚拟功能 BAR 映射的 MMIO 寄存器等位置;此类配置变更应视为恶意行为,必须将 TDI 从 CONFIG_LOCKED/RUN 状态转换至 ERROR 状态。

若 DSM 或设备其他逻辑部分遇到无法恢复的错误或故障,导致 DSM 丢失 TDI 状态,必须将设备转换至安全故障状态,将处于 CONFIG_LOCKED/RUN 状态的 TDI 转换至 ERROR 状态。

11.4.6 数据完整性错误

处于 RUN 状态的接口收到带毒 TLP(Poisoned TLP),表明发生不可纠正的数据完整性错误;收到此类 TLP 必须将接口从 RUN 状态转换至 ERROR 状态,以防止错误数据的使用和传播。

建议设备在其内部数据缓冲区和缓存上实现奇偶校验或 ECC(纠错码)等适当的保护方案,以检测数据完整性错误;若检测到不可纠正的数据完整性错误,必须将受影响的接口从 CONFIG_LOCKED/RUN 状态转换至 ERROR 状态,并向请求方发送带毒信号(如适用)。设备可提供机制报告并记录此类错误的发生,但必须清理并清除日志和报告寄存器中可能泄露机密数据的信息(如校验子)。

11.4.7 调试模式

设备可支持多种调试模式或调试能力:

  • 部分调试能力(如收集统计信息、错误日志等)不得影响设备安全性,也不得导致 TVM 提供给设备的数据的机密性或完整性受损;

  • 调试配置(如非侵入式调试模式或侵入式调试模式)可在 SPDM 测量中报告;DICE 设备可在 DICE TCB 信息中报告操作标志(如调试模式);

  • 其他调试模式可能允许调试器绕过签名验证、跟踪设备总线上的数据流、影响测量过程本身等,从而影响设备安全性。设备可支持并使用调试模式身份证书,标识此类调试模式的激活状态;这使 TVM(及远程验证器)能够判断是否可向设备提供机密信息。

支持 TEE-I/O 的设备可将此类调试模式的授权限制在冷复位后的早期窗口期内(即调试授权在向设备提供机密信息或解锁设备内部机密信息前执行);当调试授权窗口处于活跃状态时,设备不得参与 SPDM 会话建立。或者,支持 TEE-I/O 的设备可允许随时执行调试授权,但在响应调试授权请求时,需先将 IDE 流状态转换至不安全状态、终止与 TSM 的 SPDM 会话、将所有处于 CONFIG_LOCKED 或 RUN 状态的 TDI 转换至 ERROR 状态,然后再启用调试接口。此类设备可确保调试器无法访问 TVM 已提供给设备的机密信息。

11.4.8 常规复位

常规复位(冷复位、热复位或温复位)会将设备的所有端口寄存器和状态机恢复至初始值,且所有 TDI 的 TDISP 状态均转换至 CONFIG_UNLOCKED 状态。

设备复位架构必须确保所有 TVM 数据、IDE 密钥、其他加密密钥(如对等链路密钥、设备内部互连密钥等)和 SPDM 会话密钥被清除,确保复位后无法通过任何机制以明文形式暴露这些信息。

设备可能在复位后授权调试;若未清理和清除流加密密钥,调试器可能通过调试工具访问这些密钥。除流加密密钥外,设备中以明文形式存储的 TVM 数据(如设备一致性缓存、寄存器文件、SRAM 等中的数据)也可能被调试器通过调试工具访问。支持 TEE-I/O 的设备必须实现适当的机制,在复位后授权调试访问前,清理设备内部结构中的残留机密信息。

设备可能在常规复位过程中断电,复位后可能无法确定设备此前是否被 TVM 使用。因此,支持 TEE-I/O 的设备应默认假设常规复位前可能存在与 TVM 关联的 TDI,并实现适当的机制,确保复位后残留数据和机密信息不会以明文形式泄露。

对于需要重新加载固件的复位,设备测量寄存器必须恢复至默认值;部分设备可能在温复位时重新加载固件,其他设备则可能需要冷复位或 D3 状态转换。

11.4.9 功能级复位

对虚拟功能(VF)或非 IOV 功能执行功能级复位,必须影响该功能承载的 TDI;对物理功能(PF)执行功能级复位,必须影响所有下属虚拟功能(VF)的 TDI。

功能级复位必须将所有受影响且处于 CONFIG_LOCKED 或 RUN 状态的 TDI 转换至 ERROR 状态;若要清理 TDI 状态并清除 TVM 数据/机密信息,需发送 STOP_INTERFACE_REQUEST 请求,将受影响的 TDI 转换至 CONFIG_UNLOCKED 状态。

功能级复位不影响活跃的 SPDM 会话或 IDE 流。

11.4.10 地址转换服务(ATS)与访问控制服务(ACS)

支持 ATS 且已启用 ATS 的 TEE-I/O 设备,必须为处于 RUN 状态的 TDI 生成 T 位为 1 的转换请求和页面请求。

若设备支持 IDE,这些请求必须通过 LOCK_INTERFACE_REQUEST 绑定到 TDI 的 IDE 流生成。

未通过默认 IDE 流发送的 ATS 请求,不得假设能准确反映该 TDI 的权限;因此,若设备缓存主机内存,不得允许 TEE TDI 与非 TEE TDI 共享该缓存值。

处于 RUN 状态的 TDI 发起的 ATS 转换请求,必须置位 T 位;收到的转换完成包也必须置位 T 位;若收到 T 位为 0 的转换完成包,必须将 TDI 转换至 ERROR 状态。

处于 RUN 状态的 TDI 仅可发起 ATS 转换读请求或写请求,且必须置位 T 位;对于处于 RUN 状态的 TDI 发起的 ATS 转换读请求,收到的完成包的 T 位可为 0 或 1。

ATS 失效请求和失效完成包消息,允许使用或不使用 IDE:

  • 若使用 IDE,对处于 RUN 状态的 TDI 的转换生效的失效请求,其 T 位可为 0 或 1;

  • 若失效请求使用 IDE,则失效完成包必须使用与失效请求相同的 IDE 流,且 T 位值必须与失效请求匹配。

页面请求消息仅可在 RUN 状态下发起,且必须置位 T 位;可将处于 RUN 状态的多个接口的页面请求分组为页面请求组(PRG);PRG 响应必须使用与对应页面请求相同的 IDE 流,且必须置位 T 位;违反此规则必须导致 TDI 转换至 ERROR 状态。

处于 RUN 状态的 TDI 生成的未转换对等(P2P)请求,必须通过将 TDI 转换至 CONFIG_LOCKED 状态时绑定的默认选择性 IDE 流,重定向到上游的根复合体。

当接口未绑定任何对等流时,处于 RUN 状态的 TDI 生成的所有转换对等请求,必须通过将 TDI 转换至 CONFIG_LOCKED 状态时绑定的默认流,重定向到上游的根复合体;当接口绑定对等流时,处于 RUN 状态的 TDI 生成的转换对等请求,可通过 BIND_P2P_STREAM_REQUEST 绑定到 TDI 的对等流发送。

支持 TEE-I/O 的设备必须确保地址转换缓存(ATC)的完整性,防止根复合体提供的转换通过不可信访问被修改。

设备对 PASID/ATS 能力的要求:

  • “支持执行权限”(Execute Permission Supported)必须置 0;

  • “支持全局失效”(Global Invalidate Supported)必须置 0;

  • 所有转换完成包中,设备必须将 G 位视为 0。

用于重定向的访问控制服务(ACS)机制,必须与设备配置协调,确保使用正确的选择性 IDE 流;具体包括:

  • ACS 转换阻断(ACS Translation Blocking);

  • ACS 对等请求重定向(ACS P2P Request Redirect);

  • ACS 对等完成包重定向(ACS P2P Completion Redirect);

  • ACS 上游转发(ACS Upstream Forwarding);

  • ACS 对等出口控制(ACS P2P Egress Control);

  • ACS 直接转换对等(ACS Direct Translated P2P)。

11.5 TDI 要求对主机安全的影响

11.5.1 地址转换

主机上运行的 TVM 所观察到的“内存为 TEE 内存或非 TEE 内存”这一属性,必须与分配给该 TVM 的 TDI 所观察到的内存视图一致。转换代理(TA)可通过 T 位为 1 标识处于 RUN 状态的 TDI 发起的请求。TVM 依赖 TSM 和 TA 对分配给 TVM 的 TDI 的请求进行转换,确保满足以下条件:

  1. 不可信 VMM 无法破坏客户物理地址(GPA)或客户虚拟地址(GVA)到物理地址(PA)的转换完整性;

  2. 转换代理(TA)确保 TDI 发起的未转换请求符合该 TDI 的访问权限;

  3. 若 TDI 中启用地址转换缓存(ATC),则该缓存必须与 TVM 关联的地址转换和保护表(ATPT)保持一致;ATPT 的变更必须被 CPU TLB、IOMMU TLB 和 ATC 同时感知;

  4. 用于 ATPT 查找的标识符(如请求方 ID(RID)和 PASID)的完整性必须经过验证,防止这些标识符被伪造;

  5. 用于处理失效完成包的标识符(如请求方 ID 和 ITAG)的完整性必须经过验证,防止这些标识符被伪造。

11.5.2 MMIO 访问控制

TSM 必须对分配给 TVM 的 MMIO 资源提供以下访问控制:

  1. 验证设备通过 DEVICE_INTERFACE_REPORT 报告的所有 MMIO 资源均已对 TVM 可见,且这些资源映射到 TVM 地址空间的顺序与预期映射顺序一致;

  2. 限制 TVM 和分配给 TVM 的 TDI,仅可访问分配给该 TVM 的 MMIO 资源;

  3. 仅允许 TVM 或该 TVM 可信计算基(TCB)中的组件(如其他处于 RUN 状态且分配给该 TVM 的 TDI)发起的访问,生成 T 位为 1 且目标为 TVM 的 MMIO 资源的 TLP。

11.5.3 DMA 访问控制

TSM 必须对分配给 TVM 的内存和 MMIO 资源提供以下 DMA 访问控制:

  • 仅允许被 TVM 纳入其可信计算基(TCB)的 TDI,通过未转换或已转换请求对 TVM 内存执行 DMA 操作;此类 DMA 可针对 TVM 的机密内存或 TVM 可访问的非机密内存;

  • 当 TVM 将某一 TDI 纳入其 TCB 时,即表示将整个设备纳入其 TCB;某一设备若被多个 TVM 纳入各自的 TCB,则该设备属于所有这些 TVM 的 TCB;

  • 将设备纳入其 TCB 的 TVM,信任该设备不会伪造用于 DMA 访问控制的标识符(如源请求方 ID(RID)和 PASID);

  • 未将某一设备的 TDI 纳入其 TCB 的 TVM,不得将该设备纳入其 TCB;此类设备不得通过未转换或已转换请求访问 TVM 的内存或 MMIO 资源。

11.5.4 设备绑定

TVM 使用 [SPDM] 规范中指定的认证和测量报告协议,在将设备纳入其 TCB 前,判断承载 TDI 的设备所报告的身份和测量信息是否可接受。TVM 还需进一步判断经认证的设备当前是否已通过 TSM 建立的 IDE 流(如适用)和 SPDM 会话与主机绑定。

TSM 必须提供可信机制,用于判断以下条件:

  1. TSM 与经 TVM 认证的设备中的 DSM 之间是否存在活跃的 SPDM 会话;

  2. TSM 是否已为该 TDI 使用的 IDE 流建立 IDE 密钥。

11.5.5 互连安全

每个 IDE 子流的对称流加密密钥和初始向量(IV)均为机密信息,泄露这些信息将破坏方案的安全性。主机必须实现足够的安全措施,防止加密密钥在存储和使用过程中泄露;不得向 TSM 和 TSM 可信计算基(TCB)外暴露流加密密钥和 IV;不得允许通过不可信机制修改流加密密钥或 IV。这些保护措施适用于所有有助于维持 IDE 流机密性和完整性的主机特定机制(如密钥集变更机制或密钥刷新计时器)。

主机必须为每个 IDE 子流编程唯一的加密密钥,且 IDE 子流密钥刷新时不得重复使用旧密钥。

11.5.6 数据完整性错误

主机必须提供数据隔离机制,防止 TVM 或 TVM 可信计算基(TCB)中的组件使用和进一步传播带毒 TLP 中的数据。

强烈建议主机在其内部数据缓冲区和缓存上实现奇偶校验或 ECC(纠错码)等适当的保护方案,以检测数据完整性错误;若检测到不可纠正的数据完整性错误,主机必须对数据进行带毒标记,防止 TVM、分配给 TVM 的 TDI 或 TVM 可信计算基中的其他组件使用和传播该数据;主机必须清理记录错误信息(如校验子)的寄存器,避免泄露机密数据。

11.5.7 TSM 对锁定根端口配置的跟踪与处理(参考性)

TSM 必须跟踪对连接处于 CONFIG_LOCKED 或 RUN 状态设备的根端口的配置寄存器或其他可变更配置控制的修改尝试。具体需跟踪的内容取决于实现,由于设备的安全属性依赖于这些机制的正确实现,强烈建议精通安全硬件构建与验证的人员深度参与所有实现的设计与验证。

表 31 提供了有关架构定义寄存器的一般指导;需评估根复合体特定寄存器,以确定是否允许修改这些寄存器;只读寄存器、硬件初始化寄存器和用于选择读取数据的寄存器(如电源预算数据选择寄存器)排除在本表之外,TSM 必须确保修改这些寄存器不会影响相关 TDI 的安全性。

表 31 根端口配置的 TSM 跟踪与处理示例

寄存器/能力/扩展能力寄存器修改的示例响应说明
缓存行大小(Cache Line Size)、延迟计时器(Latency Timer)、中断线(Interrupt Line)允许-
命令寄存器(Command)参见说明清除以下位将导致承载的 IDE 流转换至不安全状态:
内存空间启用(Memory Space Enable)、总线主控启用(Bus Master Enable);
其他位的修改允许。
状态寄存器(Status)允许-
BIST 寄存器(BIST Register)、基地址寄存器(Base Address Registers)、扩展 ROM 基地址(Expansion ROM Base Address)、主总线号(Primary Bus Number)、次总线号(Secondary Bus Number)、从属总线号(Subordinate Bus Number)、根端口段号(Root Port Segment Number)错误将承载的 IDE 流转换至不安全状态。
I/O 基址/I/O 限值(I/O Base/I/O Limit)允许-
次级状态寄存器(Secondary Status Register)允许-
内存基址/内存限值(Memory Base/Memory Limit)错误将承载的 IDE 流转换至不安全状态。
可预取内存基址/可预取内存限值(Prefetchable Memory Base/Prefetchable Memory Limit)错误将承载的 IDE 流转换至不安全状态。
I/O 基址高 16 位/I/O 限值高 16 位(I/O Base Upper 16 Bits/I/O Limit Upper 16 Bits)允许-
桥控制寄存器(Bridge Control)允许-
电源管理能力(Power Management Capability)允许若电源转换导致端口丢失状态,则该端口承载的 IDE 流转换至不安全状态。
设备控制寄存器(Device Control)参见说明修改“扩展标签字段启用”(Extended Tag Field Enable)必须导致该端口承载的流转换至不安全状态。
设备状态寄存器(Device Status)允许-
链路控制寄存器(Link Control)参见说明禁用链路或重新训练链路,将导致根端口中配置的 IDE 流转换至不安全状态。
链路状态寄存器(Link Status)、链路状态 2 寄存器(Link Status 2)允许-
插槽状态寄存器(Slot Status)允许-
根控制寄存器(Root Control)允许-
根状态寄存器(Root Status)允许-
设备控制 2 寄存器(Device Control 2)参见说明修改“10 位标签请求方启用”(10-bit Tag Requester Enable)的状态,将导致该端口承载的流转换至不安全状态;其他位的修改允许。
设备控制 3 寄存器(Device Control 3)参见说明修改“14 位标签请求方启用”(14-bit Tag Requester Enable)的状态,将导致该端口承载的流转换至不安全状态;其他位的修改允许。
链路控制 2 寄存器(Link Control 2)、链路控制 3 寄存器(Link Control 3)参见说明允许修改这些寄存器;若修改导致链路故障,则该端口中配置的 IDE 流转换至不安全状态。
MSI、MSI-X允许-
次级 PCIe(Secondary PCIe)、物理层 16.0 GT/s(Physical Layer 16.0 GT/s)、物理层 32.0 GT/s(Physical Layer 32.0 GT/s)参见说明允许修改这些寄存器;若修改导致链路故障,则该端口中配置的 IDE 流转换至不安全状态。
接收器通道裕量(Lane Margining at the Receiver)参见说明允许修改这些寄存器;若修改导致链路故障,则该端口中配置的 IDE 流转换至不安全状态。
ACS(访问控制服务)允许-
延迟容限报告(Latency Tolerance Reporting)允许-
L1 PM 子状态(L1 PM Substates)参见说明允许修改这些寄存器;若修改导致链路故障,则该端口中配置的 IDE 流转换至不安全状态。
高级错误报告(Advanced Error Reporting)允许如 6.2.3.2.2 节所述,错误掩码寄存器设置控制检测到错误的报告,但不阻止错误检测。
增强分配(Enhanced Allocation)错误将承载的 IDE 流转换至不安全状态。
可调整大小 BAR(Resizable BAR)错误将承载的 IDE 流转换至不安全状态。
FRS 排队(FRS Queueing)允许-
扁平化端口桥(Flattening Port Bridge)错误将承载的 IDE 流转换至不安全状态。
虚拟通道(Virtual Channel)允许——参见说明当 TC/VC 映射变更或仲裁表更新时,根端口必须强制执行事务排序。
供应商特定(Vendor Specific)参见说明由供应商根据 TDISP 提供的安全原则分析。
供应商特定扩展(Vendor Specific Extended)参见说明由供应商根据 TDISP 提供的安全原则分析。
指定供应商特定(Designated Vendor Specific)参见说明由供应商根据 TDISP 提供的安全原则分析。
RCRB 头部(RCRB Header)允许-
根复合体内部链路控制寄存器(Root Complex Internal Link Control)参见说明允许修改此寄存器;若修改导致链路故障,则该端口中配置的 IDE 流转换至不安全状态。
多播(Multicast)错误TEE-I/O 操作不支持启用多播机制;将承载的 IDE 流转换至不安全状态。
动态功率分配(Dynamic Power Allocation)允许根端口必须防止自身运行超出规格;若根端口无法通过节流、频率控制等机制在功率分配范围内可靠运行,则必须将承载的 IDE 流转换至不安全状态。
TPH 请求方(TPH Requester)允许-
DPC(向下端口控制)允许-
精确时间管理(Precision Time Management)允许-
原生 PCIe 机框管理(Native PCIe Enclosure Management)允许-
替代协议(Alternate Protocol)允许-
系统固件中介(SFI,System Firmware Intermediary)允许-
协议多路复用(Protocol Multiplexing)允许支持 PMUX(协议多路复用)的根端口,不得使用 PMUX 数据包传输或接收 IDE TLP;若修改导致链路故障,则该端口中配置的 IDE 流转换至不安全状态。
数据对象交换(Data Object Exchange)允许-
完整性与数据加密(Integrity and Data Encryption)参见说明修改绑定到分配给 TVM 的 TDI 的流的流控制寄存器、选择性 IDE RID 关联寄存器或选择性 IDE 地址关联寄存器,属于错误,该流将转换至不安全状态。
碎片错误注入(Flit Error Injection)参见说明允许修改此寄存器;若修改导致链路故障,则该端口中配置的 IDE 流转换至不安全状态。

11.5.8 IDE 扩展能力寄存器

主机必须确保用于配置 TEE-I/O 流的根端口的 IDE 扩展能力寄存器的完整性。可通过以下机制(及其他机制)提供此类完整性保护:

  1. 限制仅 TSM 或 TSM 可信计算基(TCB)中的组件对这些寄存器的写访问;

  2. 若检测到 TSM 或 TSM 可信计算基外的实体尝试修改这些寄存器,将对应的 IDE 流转换至不安全状态。

TSM 可提供接口,允许 VMM 管理用于 TEE-I/O 的 IDE 流的生命周期;VMM 可使用此 TSM 提供的接口配置、启用、禁用和回收(包括非正常关闭/回收)流控制寄存器。TSM 向 VMM 提供的此类接口的细节,不在 TDISP 范围内。

11.6 威胁模型与缓解措施概述

本节提供简要概述;强烈建议由专业安全人员对所有实现进行全面的威胁模型分析。

11.6.1 互连安全

用于将设备连接到主机的互连,需防范链路上的物理攻击威胁。攻击者可能使用实验室设备、中介器、定制设备、交换机固件修改、交换机器路由表修改、交换机和中继器中的调试钩子等工具,捕获传输数据、重新排序数据或丢弃链路上传输的数据。

攻击者可能具备对互连协议不允许的事务重新排序的能力;可能尝试重新编程与链路保护方案相关的加密密钥和重放保护计数器,以破坏链路上事务的机密性或完整性,或重放链路上的事务;还可能构建定制设备或利用可信设备中的漏洞,尝试伪造互连协议中使用的标识符(如 RID、PASID),以绕过基于这些标识符的访问控制。

这些威胁可通过使用 IDE 保护承载 TVM 数据的 TLP 来缓解:

  • TLP 头部的完整性保护有助于检测 RID、PASID 等标识符的篡改;

  • 选择性 IDE 流的使用,可检测请求方使用超出 RID 关联寄存器定义范围的 RID 的尝试;

  • 设备和主机对 IDE 密钥和 SPDM 安全会话密钥的保护,防止 TVM 可信计算基(TCB)外的实体获取这些密钥;

  • 设备检测 IDE 配置的修改并将相关 TDI 转换至 ERROR 状态;

  • 若 SPDM 会话进入会话终止阶段,所有通过该会话建立密钥的 IDE 流均转换至不安全状态,且所有通过该会话转换至 CONFIG_LOCKED 状态的 TDI 均转换至 ERROR 状态;

  • 主机可防止 IDE 配置被修改,或在检测到修改时将 IDE 流转换至不安全状态;

  • TDI 仅可与通过用于 LOCK_INTERFACE_REQUEST 的同一 SPDM 安全会话配置密钥的 IDE 流关联;

  • TDI 仅可与通过用于 BIND_P2P_STREAM_REQUEST 的同一 SPDM 安全会话配置密钥的对等 IDE 流关联;

  • IDE 流转换至不安全状态时,相关 TDI 转换至 ERROR 状态。

主机还应通过特定于实现的机制,防范以下额外威胁(以保障 IDE 和 TEE-I/O 的安全):

  • 保护主机用于将地址路由到根端口的配置,防止事务被重定向到非预期目标(如 TVM 发起的设备内存事务、通过主机路由的对等请求、设备发起的主机内存事务);

  • 防止主机根端口和其他逻辑块被复位至硬件初始化(HwInit)状态;

  • 防范影响 IDE 密钥、IV、路由配置及其他影响 TEE-I/O 安全目标的主机功能的调试模式。

11.6.2 身份与测量报告

攻击者可能构建模仿合法设备但具有恶意行为的定制设备,以破坏提供给该设备的 TVM 机密数据的机密性和/或完整性;可能控制加载到可信设备中的固件版本,利用特定版本固件中的漏洞;可能调用设备支持的调试能力,影响设备中数据的机密性和/或完整性或设备的功能操作;可能通过物理访问或访问本地/远程调试接口等方式,尝试破坏设备的信任根(包括设备信任根提供的测量、报告、身份、授权或更新服务);可能具备降级设备固件的能力(在 TVM 验证测量后),并利用降级版本中的漏洞;可能控制加载到主机中 TVM 信任边界内的固件/软件组件版本,利用特定版本固件/软件中的漏洞;还可能通过物理访问主机或访问本地/远程调试接口等方式,尝试破坏主机中的 TVM 信任根。

这些威胁可通过使用 [SPDM] 进行身份和测量报告来缓解:

  • 设备实现安全机制保护设备中的信任根,通过安全机制配置设备信任根,实现安全的测量信任根(RTM)并保护测量寄存器的完整性,防止调试模式破坏信任根(RoT)和测量信任根(RTM);

  • TSM 向 TVM 提供设备绑定信息,使 TVM 能够通过 11.2.7 节中概述的问题,判断是否将处于安全状态的设备纳入其 TCB。

11.6.3 TDI 分配与分离

将 TDI 分配给 TVM,包括向 TDI 提供 MMIO 资源访问权限,以及建立 TDI 对 TVM 内存的 DMA 访问控制。

攻击者(可能是 TVM 信任边界外的软件,包括其他 TVM、TVM 不信任的设备,或使用调试接口的攻击者等)可能影响分配给 TVM 的 MMIO 资源的正确性和/或完整性,以及 DMA 转换表的正确性和/或完整性;例如,不可信 VMM 或 TVM 信任边界外的软件控制的 TDI(包括不相关/不可信的 TVM),可能尝试恶意访问分配给 TVM 的 MMIO 资源,以破坏设备中寄存器和 MMIO 映射资源的机密性和/或完整性;不可信 VMM 可能以错误顺序映射分配给 TVM 的 MMIO 资源,诱骗 TVM 访问 TDI 中错误的寄存器和/或资源;攻击者可能利用地址解码优先级等属性,通过向多个 TDI 分配重叠的 MMIO 资源来重定向事务;可能重新编程 TVM 正在使用的 TDI,以影响 TDI 的功能,破坏链路上事务的机密性和/或完整性或 TDI 中的机密数据(如修改设备的 MMIO BAR 以丢弃事务);可能通过向设备发送复位命令异步更改设备状态,导致设备在 TVM 活跃使用时丢失已建立的保护;还可能启动恶意构建的 TVM,与攻击者协作破坏其他 TVM 数据的机密性和完整性。

这些威胁可通过使用 TDISP 来缓解:

  • TDISP 提供协议和安全要求,通过 LOCK_INTERFACE_REQUEST 锁定 TDI 配置,通过 GET_DEVICE_INTERFACE_REPORT 获取锁定 TDI 的报告,通过 START_INTERFACE_REQUEST 安全启用 TVM 访问的内存空间和 DMA;

  • 设备在 TDI 转换至 CONFIG_LOCKED 状态时生成随机数,在请求转换至 RUN 状态时验证该随机数,确保 TDISP 状态机的所有转换均由同一 SPDM 安全会话中生成的 TDISP 请求触发;

  • DEVICE_INTERFACE_REPORT 提供 TDI 配置、相关 MMIO 资源列表及这些资源映射到 TVM 地址空间的预期顺序的可信报告;

  • TVM 和 TSM 使用 DEVICE_INTERFACE_REPORT 确保 TDI 的所有 MMIO 资源均分配给该 TDI 所属的 TVM,且 MMIO 资源按预期顺序映射到 TVM 地址空间;

  • 11.5.1 节规定了 TSM 对地址转换完整性的强制要求;

  • 11.5.2 节规定了 TSM 对 MMIO 访问控制的强制要求;

  • TSM 通过这些访问控制机制,确保仅分配了 MMIO 资源的 TVM 可生成 T 位为 1 的访问请求;

  • 处于 RUN 状态的设备,仅允许 T 位为 1 的请求访问 IS_NON_TEE_MEM 为 0 的内存;

  • 若设备支持 IDE 能力,仅允许通过绑定到 TDI 的 IDE 流访问 IS_NON_TEE_MEM 为 0 的内存;

  • TSM 通过特定于主机的机制强制 DMA 访问控制;

  • TSM 使用 STOP_INTERFACE_REQUEST 确保在回收分配给 TVM 的资源前,TDI 中排队的所有工作已排空并停止;

  • 仅当主机支持 ATS 转换且根复合体在 ATS 转换请求发起时执行正确的 TEE 访问检查时,TSM 才允许通过 BIND_P2P_STREAM_REQUEST 消息绑定对等流;

  • 收到解析为对等流描述地址的转换完成包时,接收设备可确保自身具备访问指定资源的完整权限;

  • 配置了对等流且收到 T 位为 1 的对等流请求时,接收设备可确保发送方具备访问指定资源的完整权限,接收方无需执行额外的访问检查;

  • 仅当请求中 MMIO 范围的页面已分配给发起请求的 TVM 时,TSM 才允许 TVM 通过 SET_MMIO_ATTRIBUTE_REQUEST 更新 TDI 的 MMIO 属性;

  • 设备跟踪处于 CONFIG_LOCKED 状态的 TDI 的配置,检测重新配置 TDI 的尝试;

  • 功能级复位将 TDI 转换至 ERROR 状态;

  • 常规复位要求设备清除残留的 TVM 机密信息、IDE 机密信息和 SPDM 会话机密信息,防止 TVM 信任边界外的实体访问这些信息。

TDISP从入门到落地:PCIe接口安全状态机与TLP过滤规则详解 随着机密计算在云计算场景中的普及,PCIe设备的安全隔离成为无法回避的技术挑战。传统IOMMU难以应对设备自身被攻破、固件篡改或恶意DMA等威胁。TDISP(TEE Device Interface Security Protocol)作为PCIe安全体系中的关键策略执行层,通过设备接口安全状态机与TLP过滤规则,实现对DMA地址、中断向量及配置访问的精细管控。它与SPDM(设备身份认证)和IDE(链路完整性与加密)协同,构成从TEE到设备功能端的可信通路。本文从威胁模型出发,拆解TDISP的核心概念、状态 阅读详情

相关推荐

TDISP(TEE Device Interface Security Protocol)软件操作流程

/ 1. SPDM会话相关定义(🔶1-37、🔶1-187)// SPDM会话ID// AES-256-GCM加密密钥(TDISP要求)// 初始向量// 会话是否激活// 2. IDE流配置(🔶1-52、🔶1-625)// IDE流ID// 4个子流的AES密钥(覆盖所有子流类型)// 密钥是否已配置// 3. TDI状态与配置(🔶1-207、🔶1-210)TDI_CONFIG_UNLOCKED = 0, // 初始配置态。

inquisiter 1432

【TEE】ARM CCA 可信计算架构

Hign Level设计安全威胁模型用法内存安全问题在本指南中,我们将探讨机密计算在现代计算平台中的作用,并解释机密计算的原理。然后,我们将介绍 Arm 机密计算架构 (Arm CCA) 如何在 Arm 计算平台中实现机密计算。定义机密计算描述一个复杂的系统信任链了解 Realm 是由 Arm CCA 引入的受保护的执行环境解释如何在 Arm CCA 的实现上创建、管理和执行 Realm定义可信执行环境 (TEE) 和 Realm 之间的区别。

qq_43543209的博客 5201

Arm TDISP协议:PCIe安全通信与机密计算实践

PCIe协议中的VDM(Vendor Defined Message)机制为设备厂商提供了扩展专有功能的标准化途径。Arm基于此开发的TDISP协议,通过硬件级安全通信保障,解决了机密计算场景中设备访问内存的安全隐患。该协议包含ARM_VDM_HEADER、REQ_RESP_HEADER等核心组件,支持内存加密上下文绑定(MECID)等关键功能。在金融云、AI推理等场景中,TDISP能有效防御DMA攻击和侧信道威胁,同时通过批处理请求和异步确认等优化手段控制性能损耗。对于开发者而言,需特别注意字节序处理和寄

weixin_30907935的博客 314

PCIe6.0学习小记

从以上图4可知,PAM4的4个电平(Level0,1,2,3)进行格雷编码(Gray Coding),4个电平对应的格雷编码分别是00,01,11,10,格雷编码的方式是要求相邻符号,每次只能变化一位,且首尾符号也只是变化一位,这样的编码方式可以有效改善误码率。在将 PAM4 电压转换为 2 位对齐量后,如果适用,它会进行接收端预编码,然后解码格雷码,如果适用,则在单比特级别进行解扰。如上图所示的对比可以看出,NRZ只有0,1两个电平,形成一个眼,而PAM4会有0,1,2,3共4个电平,形成了3个眼。

Summer的博客 4585

TDISP协议详解:PCIe安全机制与TLP规则入门

PCIe作为高速互联的基石,长期假设设备可信,但在虚拟化与云计算场景下,DMA攻击成为严峻威胁。IOMMU虽能限制设备访问窗口,却无法防御设备自身被攻破后的恶意行为。为解决这一信任危机,PCIe安全体系引入SPDM、IDE与TDISP三方协作:SPDM负责设备身份认证与密钥协商,IDE提供TLP层端到端的机密性与完整性保护,TDISP则依据安全状态控制DMA接口的放行权限。而这一切最终落到事务层包TLP的规则上,包括ICV校验、选择性IDE流配置以及TDI状态机迁移。理解这些机制,是FPGA加速卡、NVMe

weixin_33912638的博客 337

TDISP协议详解:PCIe设备安全与TLP规则实战指南

在PCIe安全体系中,TEE(可信执行环境)与设备间的安全通信至关重要。TDISP(TEE Device Interface Security Protocol)作为设备接口安全协议,基于SPDM身份认证和IDE链路加密,通过定义设备安全状态(如Unlocked、Locked、Running)和TLP报文规则,确保设备在机密计算中被安全分配。其技术价值在于防止TOCTOU攻击,保障数据在设备内部的安全上下文。应用场景包括数据中心GPU、加速卡等设备的机密计算。本文深入解析TDISP的信任模型、TLP规则及实

weixin_28721917的博客 134

TDISP详解:从PCIe TLP规则到TEE设备安全状态机

PCIe设备凭借DMA能力可直读系统内存,但这也让恶意固件有机可乘。传统IOMMU能从主机侧限制DMA地址范围,却无法判断设备所处的安全上下文。TEE场景下,CPU机密内存需要外设可信,于是设备接口安全协议TDISP应运而生。TDISP基于SPDM会话,将PCIe设备安全能力抽象为状态机,从Not Configured到Secure逐级推进,并在每个状态下定义严格的TLP规则:地址窗口、请求类型、长度边界均需校验,Secure状态还常配合IDE加密链路数据。本文梳理TDISP在PCIe协议栈中的位置,拆解D

weixin_34161029的博客 371

VMProtect虚拟机保护及还原

VMProtect虚拟机保护及还原

ZK_1874的博客 3113

Security Protocol and Data Model (SPDM) Specification

SPDM(Security Protocol for Data Mobility)是一种安全协议,用于保护数据在移动存储设备之间的安全性和完整性。它是由 Trusted Computing Group (TCG) 的 Storage Work Group 开发的一个规范,旨在为存储设备提供一个安全的数据传输和存储环境。SPDM 协议的目标是确保数据在设备之间移动时不会被未授权访问、篡改或泄露。:SPDM 允许设备相互验证对方的身份,确保数据传输是在可信的设备之间进行。

智小星的博客 1万+

【信息科学与工程学】计算机科学与自动化——第一百八十九篇 计算机硬件 系列一 微处理器01

在金融行业CDN流推送场景中,结合WebRTC over SD-RTN与SD-WAN Branch方案,需兼顾​​要求。

weixin_49199313的博客 1056

SAP软件外币评估系统配置与操作

文章摘要:本文详细介绍了SAP系统中外币评估的流程、策略及系统操作。外币评估是期末关账的重要环节,主要针对外币未清项目及资产/负债进行汇率重估,生成评估差异过账以反映真实财务状况。文中阐述了三种评估策略(不评估、增量评估、期末评估冲回)及适用场景,并提供了SAP系统外币评估的具体操作步骤(FAGL_FCV/FAGL_FC_VAL事务码)。同时,讲解了货币资金科目和未清项管理科目的评估差异处理方式,以及相关的系统配置(OB59、OBA1等)。文章还区分了已实现和未实现汇兑损益的会计处理,为企业外币业务管理提供

weixin_40672823的博客 1962

I/O 虚拟化原理

I/O虚拟化技术主要分为三种实现方式:1)纯软件模拟(如QEMU),通过完全模拟硬件设备实现最佳兼容性但性能较差;2)半虚拟化(如VirtIO),采用前后端驱动和共享内存机制,在兼容性和性能间取得平衡;3)硬件辅助虚拟化(如SR-IOV),通过物理设备直接虚拟化实现接近原生性能。关键技术包括地址转换(GPA/HPA)、IOMMU隔离、中断虚拟化等。三种方案各具特点:全模拟兼容性最好但性能最低,VirtIO是通用云方案,SR-IOV适合高性能场景但依赖硬件支持。I/O虚拟化本质是通过不同层级的技术手段实现设备

tangzhangyin的专栏 782

Android HWC硬件合成器实战:从SurfaceFlinger到显示驱动的完整流程解析

本文深入解析Android HWC硬件合成器从SurfaceFlinger到显示驱动的完整流程,揭示HWC如何优化图形性能并降低功耗。通过实战案例和调试技巧,帮助开发者掌握硬件加速的图层混合技术,提升移动设备的显示效率。

gaochao的博客 494

DJI Payload-SDK认证芯片(CC)技术解析与实践指南

### 1.1 认证芯片的加密机制基础 认证芯片(Certified Chip,CC)是DJI Payload-SDK生态中的安全核心,采用硬件级加密实现无人机与第三方负载设备的双向身份验证。其核心加密机制基于非对称加密算法,通过以下流程确保通信安全: - **密钥交换**:设备上电后,认证芯片与无人机飞控系统进行公钥交换 - **身份验证**:双方使用预存的根证书验证对方身份合法性 - **会话

gitblog_01166的博客 376

Qcom camera hal简介

Qcom camera hal简介

weixin_42136255的博客 7764

健康保险费用预测:可解释机器学习在精算建模中的实战落地

健康保险费用预测是医疗AI与保险科技交叉领域的核心任务,本质是基于临床变量与社会因素对个体医疗支出进行风险量化。其技术原理需兼顾统计建模能力与监管可解释性,XGBoost+SHAP组合因支持特征归因、边际效应分析和临床可干预推演,成为保险精算场景的主流选择。该技术显著提升保费定价精度、降低偿付风险,并支撑DRG费用预警、团险核保辅助及再保险尾部风险评估等关键应用。本文聚焦真实产线中的时间序列验证、临床分层特征工程与监管红线指标(如Bias@90th、Calibration Slope),深入解析如何让模型不

weixin_33702545的博客 306

mineflayer 的 unstable API:深入解析 bot._client 与底层网络协议访问

本文以 mineflayer 官方文档 [docs/unstable_api.md](https://link.gitcode.com/i/4e6d4581ea21b772dea908c9916f3666) 为核心,系统讲解以 `bot._` 开头的"不稳定 API"——重点是 `bot._client`。你将理解它是什么、为何不稳定、在哪些特殊场景下才有必要使用,以及如何结合源码安全地收发原始数

gitblog_00151的博客 834

基于百度地图API在AI Studio上的卫星地图块图像处理与分类

本项目基于百度地图API获取了不同的瓦片地图并进行合并等处理,可用于遥感和抽象地图的地图块的图像分类、分割、检测等数据的制作。瓦片地图金字塔模型是一种多分辨率层次模型,从瓦片金字塔的底层到顶层,分辨率越来越低,但表示的地理范围不变。首先确定地图服务平台所要提供的缩放级别的数量N,把缩放级别最高、地图比例尺最大的地图图片作为金字塔的底层,即第0层,并对其进行分块,从地图图片的左上角开始,从左至右、从上到下进行切割,分割成相同大小(比如256x256像素)的正方形地图瓦片,形成第0层瓦片矩阵;

斌擎科技 746

【无标题】获取sts临时凭证

关于如何生成sts临时凭证访问oss,仅是自己成功的小例子,不足的地方望大哥纠正

2401_86726847的博客 275

AIGC算法工程师面试八股文深度解析与进阶指南:揭秘Diffusion Models核心原理与实战技巧

总结来说,Cosine Noise Scheduler 的核心优势在于它能够更巧妙地平衡信号和噪声的比例,在扩散过程的早期阶段更长时间地保留原始图像的细节信息,从而为去噪模型提供一个更友好的学习环境,最终带来更优异的生成质量。🚀

FJN110的博客 346

【华为OD机试真题】29、组成最大数 | 机试真题+思路参考+代码解析 (C++、Java、Py、C语言、JS)

题目描述 >小组中每位都有一张卡片,卡片上是6位内的正整数,将卡片连起来可以组成多种数字,计算组成的最大数字

KJ.JK 2418

基于Evilginx的高校MFA绕过攻击机制与防御体系研究

本文基于对公开样本、DNS日志及网络流量的深度分析,系统还原了该攻击的技术全貌:从高度仿真的钓鱼页面生成、实时会话劫持,到利用高校IT架构分散性实现横向渗透。尽管多数高校已部署多因素认证(MFA)以强化身份安全,但2025年Infoblox披露的钓鱼行动表明,传统基于时间令牌(TOTP)或短信验证码的MFA在面对Adversary-in-the-Middle(AiTM)攻击时存在根本性脆弱性。本文系统分析了基于Evilginx的高校MFA绕过攻击,揭示了传统多因素认证在面对实时会话劫持时的根本缺陷。

1027

UCIE Specification详解(三)

Protocol Layer(协议层)以及Die-to-Die Adapter

Crazzy_M的博客 1762

【VSCode智能体会话迁移全攻略】:3步实现云端无缝转移,效率提升90%

轻松实现VSCode智能体会话云端转移,解决多设备协同难题。通过导出配置、同步数据、恢复会话三步操作,适用于远程办公与团队协作场景,提升开发效率达90%。配置无缝迁移,工作连续性更强,值得收藏。

DebugLoom的博客 719

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

HTTP详解(笔记)

HTTP详解

qq_53555672的博客 1919

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

上一篇: PCIE DOE(Data Object Exchange) 软件执行流程
下一篇: IDE Key Management的密钥协商过程
inquisiter
博客等级 码龄10年 374粉丝 228原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值