TPM 2.0 与 Secure Boot 工程

• enclave 的用户态受保护内存
• MEE 硬件加密
• 可信边界与隔离

SGX 的 enclave 是受硬件保护的用户态内存区域，代码和数据在其中执行与存储，即使操作系统或 hypervisor 被攻破也无法读写 enclave 内容。Enclave 内存由 MEE（Memory Encryption Engine）在内存总线上加密，防止物理内存攻击（cold boot、DMA 攻击）与恶意软件读取。Enclave 建立了新的信任边界：CPU 是信任根，应用代码与数据在 enclave 内保持机密性和完整性，OS 被视为不可信。工程语义上，SGX 让云租户在自己的程序内隔离敏感数据，如密钥、算法参数，即使云平台被攻破也保护数据。

"用户态加密内存 + 硬件 MEE"使 SGX 在不受信任的操作系统之上提供机密计算能力，是可信执行环境（TEE）的代表。

• EPC 存储 enclave 页
• MEE 内存加密与完整性
• 硬件级防护

EPC（Enclave Page Cache）是存储在片内 EPC 内存中的受保护页表，用于存放 enclave 的代码和数据，CPU 通过 EPC 管理 enclave 页的分配与访问控制。MEE（Memory Encryption Engine）在内存控制器上对 EPC 进行加密与完整性校验，防止物理攻击（如 probe、monkey 攻击）和篡改。工程价值在于：硬件层加密与完整性保证 enclave 内容在内存中不可读、不可改，即使攻击者获得物理内存访问或控制 OS/管理程序，也无法获取或篡改 enclave 数据。这为机密计算提供了硬件信任根。

EPC 提供逻辑隔离，MEE 提供物理加密与完整性，二者协同构成 SGX 内存保护的核心硬件机制。

• SGX 1 静态内存分配
• SGX 2 动态内存管理（EAUG、EMODPE）
• 多线程与 EENTER 支持

SGX 1 要求 enclave 在构建（ECREATE）时一次性分配全部内存，运行期间无法动态增加或修改内存，灵活性受限。SGX 2 引入动态内存管理，允许运行时通过 EAUG 动态添加 EPC 页、用 EACCEPT 接受新页、用 EMODPE 修改页权限（如将只读变为可写），从而支持动态扩展、动态代码与更灵活的内存布局。SGX 2 还增强多线程支持（如并发 EENTER 与线程管理）。工程上，SGX 2 让 enclave 能根据运行时需求调整内存，降低内存预留开销，支持更复杂应用。

SGX 2 的动态内存管理（EAUG/EACCEPT/EMODPE）突破了 SGX 1 的静态分配限制，是下一代 SGX 的关键增强。

• SEV 的 guest 内存加密
• SME 引擎
• 加密密钥与 VMPL

AMD SEV 使每个虚拟机（guest）的内存由硬件 SME（Secure Memory Encryption）引擎以独立密钥加密，guest 内存的明文在写入内存前被加密，读取时解密，hypervisor 或其它 VM 无法读取 guest 内存明文。SEV 通过 ASID（Address Space ID）将每个 guest 的加密密钥与其绑定，16 位 ASID 标识加密上下文。SEV-ES（Encrypted State）进一步加密 guest 寄存器状态，SEV-SNP 增加完整性保护。工程价值在于，即使云平台 hypervisor 被攻破，也无法解密 guest 数据，实现机密计算。

SME 引擎按 guest 独立密钥加密内存，密钥与 ASID 绑定，使 VM 数据在硬件层面隔离，是 AMD 机密计算的核心。

• CCA 的 Realm 隔离
• 联邦学习与 AI 推理的机密性
• 数据与模型保护

ARM CCA 通过 Realm 机制将工作负载与 hypervisor、OS 隔离，形成机密计算环境。在联邦学习中，各参与方的数据与模型更新在 Realm 内加密处理，避免明文暴露给云端或其它参与方，实现隐私保护下的协作训练。在机密 AI 推理中，模型参数与用户输入都在 Realm 内受保护，云服务商无法窥探模型或数据，既保护模型知识产权，也保护用户数据隐私。工程价值在于，CCA 让云端 AI 服务在不可信云平台上仍能保持数据与模型的机密性和完整性，是隐私计算的关键基础设施。

CCA 的 Realm 隔离使加密 AI 工作负载在云端安全运行，支撑联邦学习与机密推理的隐私与 IP 保护。

• RME 与 Realm 概念
• Realm 与 Normal World 隔离
• 硬件信任根

ARM CCA 通过 Armv9-A 的 RME（Realm Management Extension）引入 Realm 世界（Realm World）。系统被划分为多个世界：Normal World（普通 OS/应用）、Realm World（受保护的 Realm）、Secure World（TrustZone）与 Root World。RME 让 VMM 对 Realm 的访问受到硬件保护，Realm 中的代码与数据对 hypervisor、OS 甚至物理攻击者都不可见。RMM（Realm Management Monitor）作为固件管理 Realm 生命周期。工程隔离价值在于，在 Normal World 的云平台上，Realm 提供了独立于 hypervisor 的机密计算边界，防止恶意虚拟化层窃取数据与模型。

RME 引入 Realm World 与硬件级世界隔离，使机密计算在不可信 hypervisor 之上仍可运行，是 CCA 的核心。

• Keystone 的开源可定制
• SGX/CCA 的厂商封闭
• 面向研究的灵活性

Keystone 是 MIT 主导的开源 TEE 框架，基于 RISC-V，完全开源、可定制，允许研究者自由修改安全监视器、运行时与驱动，便于安全研究和教学，也适合需要定制 TEE 的硬件平台。Intel SGX 和 ARM CCA 是厂商专有实现，接口封闭、不可修改，安全性依赖厂商，但生态成熟、性能优化好、有广泛硬件支持。工程取舍上，Keystone 提供最大可定制性与透明度（可审计），但需要自行验证与维护；SGX/CCA 提供现成、可靠、商用级方案，但缺乏灵活性。

开源可定制（Keystone）与商用成熟（SGX/CCA）的取舍，本质是"灵活可控"与"成熟可靠"之间的权衡。

• sealed object 与 PCR 绑定
• TPM2_Unseal 的验证流程
• 防篡改释放

TPM 2.0 的 sealed object（密封对象）允许将密钥或数据"密封"到一组特定的 PCR 值上。创建时记录当前 PCR 状态，解锁（unseal）时必须提供匹配的授权并满足 PCR 条件。当系统尝试 TPM2_Unseal 时，TPM 会比较当前 PCR 值与密封时绑定的 PCR 值，若两者不一致（说明引导链被篡改、替换了固件或内核），TPM 拒绝释放密钥。这使密钥仅在系统处于可信状态时才能被使用，实现了"系统可信才给密钥"的绑定，是 BitLocker 等磁盘加密防篡改的关键。

密封把密钥与 PCR 度量绑定，unseal 强制 PCR 匹配，因此任何引导链变更都会导致密钥无法释放，实现硬件级防篡改。

• FIPS 140-2 Level 3/4 等级
• tamper-evident vs tamper-resistant
• 物理攻击防护

HSM 通过 FIPS 140-2 认证分级其物理安全。Level 3 要求 tamper-evident（防篡改检测）：物理入侵会被检测并留下痕迹，且关键密钥在物理篡改时被清零；Level 4 要求 tamper-resistant（防篡改抵抗）并保护环境干扰（温度、电压），能在检测到攻击时主动清除密钥。tamper-evident 指"能发现被篡改"，tamper-resistant 指"难以通过篡改获得密钥"。工程语义上，等级越高，HSM 对物理攻击（探针、侧信道、拆解）的防护越强，适用于高价值密钥保护场景。

FIPS 140-2 等级定义了物理防护强度，Level 3/4 通过 tamper 检测/抵抗与密钥清零机制保护密钥免受物理攻击。

• CA 根签名私钥保护
• 数据库 TDE 密钥管理
• TLS 私钥保护

HSM 在多个场景保护密钥：在 PKI 中，CA 的根证书私钥与中间 CA 私钥存放于 HSM，签名操作在 HSM 内完成，私钥永不离开硬件，防止私钥泄露导致信任链崩溃；在数据库 TDE 中，HSM 作为外部密钥管理（如 Oracle TDE、SQL Server EKM），托管数据加密密钥（DEK）与主密钥（KEK），加密/解密操作在 HSM 内进行；在 SSL/TLS 中，Web 服务器私钥放于 HSM，由 HSM 完成 RSA 解密或 ECDH 计算，提升私钥安全。工程价值在于，HSM 提供 FIPS 认证的硬件级密钥保护与安全执行环境。

HSM 的核心价值是"私钥永不离开硬件 + 硬件内执行密码操作"，广泛用于 PKI、TDE 与 TLS 等关键私钥场景。

• FIPS 140-2 Level 3 认证
• SCP03 安全通道
• 设备与主机的安全通信

YubiHSM2 是获得 FIPS 140-2 Level 3 认证的经济型 HSM，提供硬件级密钥保护与安全操作。SCP03（Secure Channel Protocol 03）是智能卡行业标准（GlobalPlatform），用于在 HSM 与主机之间建立相互认证、加密的通信通道，防止中间人攻击与密钥窃听。工程价值在于：FIPS Level 3 保证物理安全与密钥清除能力，SCP03 保证主机与 HSM 通信的机密性与完整性，两者结合使 YubiHSM2 在低成本的部署中提供可靠的安全密钥管理与安全通信。

FIPS 认证保障硬件安全，SCP03 保障通信安全，二者共同为 YubiHSM2 提供端到端的密钥保护。

• out-of-order execution
• 权限检查与 page fault
• 瞬态指令与 cache 侧信道

Meltdown（CVE-2017-5754）利用 CPU 的乱序执行（out-of-order execution）绕过权限检查。在乱序执行中，CPU 会投机执行后续指令而延迟权限检查：当用户态指令尝试读取内核地址时，本应触发 page fault（权限例外），但 CPU 在检查权限前已瞬态执行了后续指令，将泄漏的内核数据作为数组索引访问 cache，从而在 cache 中留下痕迹。随后通过 cache 时间侧信道（timing-based side channel）测量哪些 cache 行被访问，逐字节恢复内核内存内容。Meltdown 是瞬态执行（transient execution）漏洞，可在无 KPTI 的系统上读取内核内存。

乱序执行"先执行后检查权限"的特性配合 cache 侧信道，使攻击者能在权限检查之前泄漏敏感数据，是 Meltdown 的机制核心。

• KPTI 原理
• 用户/内核页表分离
• 性能开销

KPTI（Kernel Page-table Isolation，又称 PTI）缓解 Meltdown 的方法：将内核地址空间与用户地址空间的内核页表分离。在用户态执行的进程，其页表中不再映射内核地址（或只映射必要的极少量内核入口），因此在用户态投机访问内核地址时，由于页表根本没有该映射，会立即触发 page fault，无法泄漏内核内存。切换到内核态时再切换为完整的内核页表。工程代价是每次系统调用/中断都要切换页表（CR3），带来额外开销（早期约 5%），后续通过 PCID 等优化降低。KPTI 让 Meltdown 的"先执行后检查"无从施展。

KPTI 通过"用户态看不到内核地址"从根上消除 Meltdown 的可利用面，代价是页表切换开销。

• 各变体的触发机制
• 权限检查差异
• 缓解手段

Meltdown 家族有多个变体，区别在于触发异常的类型。Meltdown-US（Supervisor Bit）利用特权位（supervisor bit）检查延迟，尝试读取内核内存；Meltdown-P（Rogue Data Cache Load）利用 page fault 检查延迟，覆盖更广的页表权限场景；Meltdown-GP 利用 general protection fault（GPF）检查延迟来读取数据。三者都依赖"权限检查延迟 + cache 侧信道"的瞬态执行，只是触发异常不同。KPTI 对多数变体有效，但个别场景仍需额外序列化指令。工程差异主要在于触发条件与缓解的有效性。

Meltdown 变体的本质相同（瞬态执行越权读），差异在于触发异常类别，KPTI 通过消除映射普遍缓解。

• 投机执行与边界检查
• 分支预测被训练
• cache 侧信道

Spectre v1（CVE-2017-5753，bounds check bypass）利用分支预测器可被训练的特性。攻击者先执行合法越界访问的代码路径，训练分支预测器使其预测"越界访问"为真，从而在后续投机执行中，CPU 跳过边界检查（bounds check）并瞬态执行越界 load，将泄露的数据作为数组索引访问 cache，留下 cache 痕迹。随后通过 cache 时间测量恢复被读取的越界数据。Spectre v1 不依赖权限检查延迟，而是利用"分支预测错误导致投机执行越界"，即使在无 KPTI 的内核也已产生影响，且更难防御。

Spectre v1 通过训练分支预测器诱导投机执行绕过边界检查，再经 cache 侧信道泄漏，是瞬态执行漏洞的典型代表。

• LFENCE 序列化指令
• bound speculation barriers
• SLH 编译器加固

Spectre v1 的防御思路是阻断或限制投机执行的越界 load。LFENCE 是序列化指令，在边界检查后插入 LFENCE 可阻止后续指令在边界检查完成前投机执行；bound speculation barriers 是在边界检查后插入屏障，阻止投机读。Speculative Load Hardening（SLH）是编译器级别的加固，通过在 load 前将投机条件与地址掩码结合，使投机 load 的地址被"清零"或无害化，即使投机执行也不会泄漏真实数据。工程上，编译器（如 LLVM/Clang）可自动插入这些序列化与掩码指令，代价是性能下降。结合硬件补丁与软件防护，多层面缓解 Spectre v1。

LFENCE/屏障阻断投机执行，SLH 将投机地址无害化，二者是编译器/软件层面的 Spectre v1 缓解，以性能换取安全。

• LVI 的瞬态值注入
• 与 Meltdown 方向相反
• SGX 场景

LVI（Load Value Injection）是 Meltdown 的反向利用。Meltdown 是"CPU 从内存中读取（泄漏）数据给攻击者"；而 LVI 是攻击者向"load 指令能看见的瞬态值"中注入（注入）数据，使 CPU 在投机执行中读取被注入的瞬态值并据此执行后续操作，从而影响程序的执行路径。典型场景是 SGX：攻击者控制内存中的可疑值，在 load 指令瞬态执行时被注入，攻击者通过观察后续投机执行指令的 cache 副作用推断注入值。LVI 需要软硬件协同缓解（在 load 后添加序列化指令），但性能开销大。

Meltdown 是"读泄漏"，LVI 是"写注入"，方向相反但都利用瞬态执行；LVI 尤其影响 SGX 等机密计算环境。

• gather 指令的瞬态执行
• 数据泄漏机制
• microcode 修复与性能开销

Downfall（CVE-2022-40982）通过 Intel AVX2/AVX-512 的 gather 指令（一次性从多个地址收集数据）在瞬态执行中泄漏其他向量寄存器或内核数据。利用 gather 指令投机执行时，CPU 可能将内部缓冲的数据（来自其他线程/进程）暴露给攻击者，攻击者通过 cache 侧信道或其他观测恢复数据。修复通过 microcode 更新在 gather 指令后插入序列化/屏障，阻止敏感数据在瞬态阶段被观测，代价是涉及 gather 指令的代码性能下降。工程上，需结合 microcode 更新与软件规避（如避免敌意多线程下使用 gather）。

Downfall 利用 gather 指令的瞬态执行泄漏数据，microcode 修复通过插入屏障阻断泄漏，以性能换取安全。

• 逐级签名验证
• shim 的作用
• 信任根（PK/KEK）

Secure Boot 建立了从固件到操作系统的逐级签名验证链。UEFI 固件（信任根，验证使用 PK 签名管理的密钥）验证 shim 的签名；shim（微软 3rd Party CA 签名）验证 GRUB 的签名；GRUB 验证 kernel 的签名；kernel 验证 initrd 的签名。每一级都验证下一级的签名，签名必须来自可信的密钥库（db 白名单），否则引导被拒绝。shim 的作用是作为一层"薄签名验证器"，允许发行版用自有密钥签名 GRUB 且兼容微软 Secure Boot 认证体系。逐级验证保证只有受信任的软件链才能启动系统，防止 bootkit 篡改引导流程。

Secure Boot 以 PK/KEK/db 为信任根，逐级验证每一环，任何一环签名无效都会终止引导，从而阻断恶意引导链。

• Secure Boot 的签名验证
• Measured Boot 的 PCR 度量
• 各自的职责

Secure Boot 与 Measured Boot 是互补的两种机制。Secure Boot 在启动时验证每个引导组件（固件、shim、GRUB、kernel）的签名，签名合法才允许运行，签名无效则拒绝引导，作用是"阻止未授权软件运行"。Measured Boot 并不阻止启动，而是对每个引导组件计算哈希（measure）并通过 TPM 的 PCR extend 操作累积到 PCR 寄存器，将这些度量值记录下来，供远程证明或本地验证系统是否处于可信状态。Measured Boot 关注"记录状态"，Secure Boot 关注"阻止运行"。二者常结合使用：Secure Boot 保证只运行可信软件，Measured Boot 记录引导状态供审计与证明。

Secure Boot 是"准入控制"（验证签名），Measured Boot 是"状态记录"（度量到 PCR），两者职责互补，共同构成可信引导。

• SIGSTRUCT 签名结构
• EINITTOKEN 与 EINITTOKEN_KEY
• enclave 启动验证

SGX 中，enclave 的签名者（如 Intel 或厂商）将 enclave 的元数据（MRSIGNER、度量、属性等）打包进 SIGSTRUCT，用私钥签名，作为 enclave 的身份证明。EINITTOKEN 是 CPU 生成的一个 token，用于授权 enclave 启动（EINIT 指令），其有效性由 EINITTOKEN_KEY 保护（EINITTOKEN_KEY 是 CPU 内部的密钥，用它对 EINITTOKEN 计算 MAC）。启动时，EINIT 指令校验 SIGSTRUCT 签名与 EINITTOKEN 合法性，token 有效才允许 enclave 运行。工程价值在于：签名确保 enclave 来自可信来源，EINITTOKEN 机制防止任意代码创建 enclave，实现 enclave 的签名与启动控制。

SIGSTRUCT 提供签名身份，EINITTOKEN/EINITTOKEN_KEY 提供启动授权，二者共同控制哪些 enclave 能被加载运行。

• SNP 启动度量
• launch measurement
• 防回滚

SEV-SNP 提供的启动度量（launch measurement）是 guest 内存镜像和固件状态的哈希/度量，guest owner 可通过 attestation report 验证 guest 是否按预期镜像启动。launch measurement 记录了 guest 的初始状态，若攻击者尝试用旧版本（有漏洞）的镜像或固件回滚启动，度量值会与预期不符，guest owner 拒绝认可或拒绝连接，从而防止回滚攻击。SNP 还通过加密的 guest 状态与内存完整性防止 hypervisor 篡改 guest。工程价值在于，启动度量让 guest owner 在远程确认 guest 可信且未被回滚到易受攻击版本。

启动度量绑定 guest 镜像状态，任何回滚都会改变度量值，使 owner 能检测并拒绝非预期状态，实现防回滚。

• VM 迁移
• 状态加密导出/导入
• 密钥与完整性

SEV-SNP 支持 VM 在不同主机间迁移。当迁移时，源主机将 guest 的加密状态（内存、寄存器、VMSA）导出（export），目标主机导入（import）。为防止状态在迁移中被篡改或窃取，导出/导入过程使用迁移密钥（migration-aware key）对状态进行加密与完整性保护，guest owner 或可信迁移代理需授权。状态导出与导入协议保证 guest 在迁移后仍保持机密性与完整性，且只迁移到受信任的目标。工程价值在于，在不破坏加密来宾机密性的前提下实现 VM 迁移，支持云平台的动态负载均衡与故障转移。

迁移状态加密导出/导入以密钥保护 guest 状态在传输中的机密与完整，是 SNP 支持安全 VM 迁移的关键。

• 本地 HSM vs 云 KMS
• 密钥管理与控制权
• 集成与合规

本地 HSM 是部署在自有的硬件设备，密钥由用户完全掌控，适合对密钥有严格控制权、合规要求高（如金融、政府）的场景，但需自行运维、容量规划与扩容。外部 KMS（如 AWS KMS、Google Cloud KMS）是云厂商托管服务，提供密钥的创建、轮换、加密解密接口，底层实际使用云厂商的 HSM 集群，用户无需管理硬件，集成便捷、弹性好，但密钥控制权在云厂商，需信任其安全边界与合规承诺。工程取舍上，本地 HSM 更适配"密钥绝对自主"与离线场景，云 KMS 更适合弹性、易集成与大规模云上应用。

本地 HSM 强调自主控制权，云 KMS 强调托管便利与弹性，选择取决于密钥控制需求、合规要求与部署位置。

• YubiHSM SDK
• yubihsm-connector 与 yubihsm-shell
• 管理命令与自动化

YubiHSM2 提供 YubiHSM SDK 用于开发和集成密钥管理功能。连接机制上，yubihsm-connector 是一个本地代理服务，它把 YubiHSM2 设备（通过 USB）暴露为本地 HTTP/REST 接口，使远程或本地客户端可通过 HTTP 访问 HSM；yubihsm-shell 是基于该接口的交互式命令行工具，提供密钥生成、导入、导出、签名、加密、对象管理等命令，也可用于脚本化。工程价值在于：SDK 与 REST 接口让 YubiHSM2 能被程序化集成（如 Kubernetes、CI/CD 签名），yubihsm-shell 便于管理与排障，支持自动化密钥管理。

yubihsm-connector 将 USB HSM 封装为 REST 接口，yubihsm-shell 与 SDK 在其上提供管理命令，支撑自动化密钥管理。

• 非对称密钥支持
• 对称密钥支持
• 密钥内操作

YubiHSM2 支持多种非对称密钥算法，包括 RSA（可到 2048/3072 等）、Ed25519（EdDSA 椭圆曲线签名）与 secp256r1（NIST P-256 椭圆曲线），用于签名、密钥交换等操作；同时支持对称密钥算法，如 aes-256（AES 加密/解密）与 hmac-sha256（HMAC 消息认证）。所有密钥都以对象形式存储在 HSM 内，加解密与签名操作在硬件内完成，私钥/密钥永不离开设备。工程能力上，YubiHSM2 提供广泛的算法覆盖，适用于代码签名、安全通信、数据加密等场景，且以低成本提供硬件级密钥保护。

支持现代非对称（RSA/Ed25519/ECC）与对称（AES/HMAC）算法，且密钥内操作，是 YubiHSM2 作为低门槛 HSM 的核心能力。

• 本地 vs 云 HSM
• 成本与规模
• 合规与集成

YubiHSM2 是低成本、本地、单机 HSM，适合小规模部署、开发测试、边缘场景，密钥自主可控且无需订阅，但容量与冗余有限，对高并发、高可用与严格合规（如要求云 HSM 的 FIPS 等级）支撑较弱。AWS CloudHSM、Azure Dedicated HSM、Google Cloud HSM 是云厂商提供的高可用、可扩展 HSM 服务，支持高并发、多租户隔离、自动备份与高等级合规认证，适合大规模 PKI、代码签名与关键业务，但需按资源付费、依赖云厂商且密钥控制权在云侧。工程取舍上，小规模与自主场景选 YubiHSM2，大规模、高可用、合规场景选云 HSM。

本地低成本单机（YubiHSM2）与云高可用 scale-out（云 HSM）的权衡，取决于规模、可用性、合规与控制权需求。

• BTB 分支目标缓冲
• 分支目标注入
• 跨进程污染

Spectre v2（CVE-2017-5715，branch target injection）利用 BTB（Branch Target Buffer）执行分支目标注入。BTB 缓存间接分支的目标地址，攻击者可以在自己的进程中用特定地址训练 BTB，使其指向受害者的某段代码目标。当受害者执行间接跳转时，CPU 可能投机地采用被污染的 BTB 目标，从而在受害者上下文执行攻击者选择的代码路径（gadget），泄漏受害者内存数据。V2 可跨进程/跨特权级工作，因为 BTB 可能不被内核对缓存刷新。缓解需结合 IBRS/IBPB、retpoline 与 STIBP 等。

攻击者用自身进程污染 BTB 使受害者间接跳转投机到恶意目标，是 Spectre v2 的机制核心，需软硬件协同缓解。

• Retpoline 返回跳板
• IBRS/IBPB 屏障
• STIBP 与 RSB stuffing

Spectre v2 的防御手段包括：Retpoline 用返回指令（ret）的序列替代间接跳转，使间接分支目标不被 BTB 预测，从而避免分支目标注入；IBRS（Indirect Branch Restricted Speculation）在特权级切换时限制间接分支的投机，防止跨特权级污染；IBPB（Indirect Branch Prediction Barrier）在上下文切换时刷新分支预测缓冲；STIBP（Single Thread Indirect Branch Predictors）限制 SMT 超线程下兄弟线程对分支预测的污染；RSB stuffing 在返回栈缓冲区（RSB）填充无害值，防止 RSB 被污染。这些手段从不同层面阻断 BTB/RSB 污染，常组合使用。

Retpoline 规避 BTB 预测，IBRS/IBPB/STIBP 限制分支预测污染，RSB stuffing 保护返回栈，各手段互补覆盖 V2 攻击面。

• KPTI 初始开销
• PCID 与 ASID 优化
• 内核优化减少切换

KPTI 初始引入时，每次系统调用/中断触发内核态与用户态切换都要切换页表（CR3 重载），导致 TLB 失效与开销，性能影响约 5%。工程优化包括：使用 PCID（Process Context ID）/ASID 让 TLB 条目区分进程上下文，避免切换时全量 TLB 刷新，仅切换 CR3 的 PCID 位；减少不必要的用户/内核页表切换；优化内核代码以降低系统调用频率与开销；以及后续 microcode 与 ISA 改进。这些优化使 KPTI 的开销降到低于 1%，在保持防御的同时大幅降低性能代价。

PCID 避免 TLB 全量刷新、减少切换开销是 KPTI 性能下降的关键，配合其他内核优化使开销从 5% 降至 <1%。

• LVI 防御的 fence 插入
• microcode 补丁
• 性能开销

LVI 的防御需要阻止被注入的 load 值被后续投机指令使用。缓解方式是在每个 load 指令后插入序列化指令（如 lfence），防止后续指令在 load 完成前投机执行，从而阻断 LVI 的瞬态值利用。由于每次 load 后都要插入 fence，频繁的序列化会显著降低 CPU 性能（尤其对内存密集的 SGX 应用）。工程上，microcode 补丁可自动插入这些 fence，但开销大，因此只对受影响的场景（如 SGX 安全边界）启用，并配合软件层面的规避（减少敏感 load 或隔离）。LVI 是较难缓解且代价高的漏洞。

每个 load 后插 fence 是阻断 LVI 的直接手段，但序列化开销巨大，需权衡性能与安全，仅对关键场景启用。

• 四种 hierarchy 的用途
• 各自授权与作用域
• 密钥管理

TPM 2.0 定义了四种 hierarchy（层级），每种有独立的授权策略与密钥作用域。Platform hierarchy 由平台固件控制，用于平台范围的操作（如 PCR 管理）；Owner hierarchy 由系统所有者控制，用于管理平台密钥与 NV 索引；Endorsement hierarchy 用于证明（attestation），其密钥（EK）由平台制造者/厂商管理，用于隐私保护；Null hierarchy 是临时层级，其密钥不持久化（重启后消失），用于无需持久化的临时用途。每种 hierarchy 的授权（如独立密码/PIN）提供了密钥管理的作用域隔离，使不同实体（平台、厂商、所有者）各自管理其密钥。

四种 hierarchy 通过授权与作用域隔离不同管理实体，Endorsement 保障证明隐私，Null 提供临时密钥，是 TPM 2.0 密钥组织的基础。

• PCR 的度量累积
• PCR0 平台固件
• PCR4 引导加载器、PCR7 Secure Boot 状态

TPM 2.0 提供 24 个 PCR（0-23），每个对引导链的某部分进行度量（哈希）并通过 extend 累积。标准用途：PCR0 度量平台固件（BIOS/UEFI 固件）；PCR1 度量主机平台配置；PCR2 度量可选 ROM 代码；PCR3 度量可选 ROM 配置与数据；PCR4 度量引导加载器（MBR/GRUB）；PCR5 度量引导配置；PCR6 度量平台状态转换；PCR7 度量 Secure Boot 状态与 Secure Boot 策略（db/KEK 等）；PCR8-15 保留给 OS 使用；PCR16 用于调试等。PCR0 与 PCR4 是 BitLocker 等常用的关键度量，PCR7 反映 Secure Boot 是否启用及策略。这些 PCR 值用于 sealed 绑定与远程证明。

PCR 按引导链逐阶段度量，PCR0/4/7 分别覆盖固件、引导加载器与 Secure Boot 状态，是可信引导与磁盘加密的核心度量。

• 各密钥类型用途
• 密钥层级与授权
• 适用场景

TPM 2.0 的密钥类型决定其用途与属性。Storage key（存储密钥）用于保护其他密钥（作为密钥的父密钥，如 SRK 存储根密钥）；Attestation key（AK）用于执行 TPM2_Quote 等证明操作的签名密钥，报告平台状态；Identity key 用于证明平台的隐私身份；Endorsement key（EK）是平台在制造时嵌入的根密钥，用于与 privacy CA 建立信任并派生 AK；Bind key 用于将数据绑定到某个 TPM 或实体（如 TPM2_PolicySecret 绑定）；Legacy key 是兼容旧版（RSA 解密/签名均可）的密钥。工程差异在于：EK/AK 用于证明，Storage 用于保护密钥层级，Bind 用于数据绑定，Legacy 兼容旧接口。

密钥类型定义了其在 TPM 密钥体系中的角色（保护、证明、身份、绑定、兼容），是构建可信应用的设计基础。

• sealed 与 PCR 绑定
• policy 授权
• unseal 条件

TPM 2.0 的 sealed object 可将密钥/数据绑定到一组 PCR 值。创建 seal 时记录当前 PCR 状态，并可通过 policy 授权（如 TPM2_PolicyPCR）进一步约束。解锁（unseal）时，TPM 必须校验当前 PCR 值与 sealed 时的 PCR 值一致，且 policy 满足，二者都匹配才释放密钥；否则拒绝。这使密钥只能在系统处于可信引导状态时被使用，任何引导组件被篡改（PCR 改变）都会导致 unseal 失败。工程价值在于，将磁盘密钥等绑定到 PCR，实现"系统可信才解锁"，防篡改与防离线攻击。

PCR 绑定 + policy 授权构成双重条件，unseal 强制 PCR 匹配，从而把密钥的使用与系统可信状态绑定。

• db 白名单
• dbx 黑名单/吊销
• KEK 与 PK 信任根

UEFI Secure Boot 使用四类密钥数据库管理签名验证。PK（Platform Key）是平台所有者的根密钥，用于管理 KEK；KEK（Key Exchange Key）用于管理 db/dbx 的更新，由平台所有者与 OS 厂商共享；db（allowed keys/signatures）是允许签名的白名单，签名在 db 中的组件可通过验证；dbx（revoked keys/signatures）是吊销名单（黑名单），即使签名在 db 中，若在 dbx 中也会被拒绝。工程语义上，PK 是信任根，KEK 授权密钥更新，db 决定"允许什么"，dbx 决定"禁止什么"，共同构成 Secure Boot 的签名验证与吊销体系。

PK→KEK→db/dbx 形成信任链与密钥管理层次，db 允许、dbx 吊销，实现对引导组件的细粒度控制。

• 微软 UEFI CA 与 3rd Party CA
• shim 的签名链
• 发行版部署

在 Secure Boot 生态中，Microsoft UEFI CA 是微软签名的内置 CA，用于签名 Windows 及其组件；Microsoft 3rd Party UEFI CA 是微软用于签名第三方（如 Linux 发行版）引导组件的 CA。Linux 的 shim 由微软 3rd Party UEFI CA 签名，因此预装 Secure Boot 的机器（含微软 CA）能验证并启动 shim；shim 再用发行版自己的密钥（或微软 CA）验证 GRUB/内核。工程价值在于：发行版将 shim 交由微软 3rd Party UEFI CA 签名，使 Linux 无需替换 PK 即可在 Secure Boot 机器上启动，实现了跨平台引导兼容与安全。

Microsoft 3rd Party UEFI CA 使 Linux shim 获得 Secure Boot 信任，从而在预装微软密钥的机器上实现安全引导，是跨发行版兼容的关键。

• dbx 吊销机制
• bootkit 利用签名
• 阻断已知恶意引导

dbx（Secure Boot Revocation List）用于吊销已被攻破或恶意的签名/证书。当 bootkit（如 BlackLotus、涉及 CVE-2020-0796 的引导漏洞）利用的引导组件签名被泄露或被发现恶意时，厂商可将这些签名加入 dbx，使 Secure Boot 即使看到被签名的恶意组件也拒绝加载。工程保护在于：dbx 让已发现的恶意代码"立即失效"，即使它持有合法签名，也能在启动时被拒绝，从而阻断已知 bootkit 的持久化。配合系统更新（如针对 BlackLotus 的 Microsoft 更新），dbx 更新是防御恶意引导链的关键手段。

dbx 是"吊销名单"，用签名层面阻断已知恶意 bootkit，即使签名看似合法，也能在加载前被拒绝。

• EK 与 AK 的关系
• privacy CA 的匿名证明
• 远程证明流程

EK（Endorsement Key）是 TPM 制造时生成的根密钥，标识该 TPM 的唯一身份，但直接用 EK 证明会泄露平台身份。AK（Attestation Key）是用于证明的派生密钥，由 EK 派生并注册到 privacy CA（隐私 CA）。远程证明流程中，平台用 AK 对 PCR 度量签名（TPM2_Quote），privacy CA 验证 AK 是由可信 EK 派生，从而在不暴露 EK 身份的前提下证明平台处于可信状态。这种"EK 信根 + AK 证明 + privacy CA 匿名化"的机制，既保障证明的可信性又保护平台隐私，是远程证明的标准设计。

EK 提供身份信根，AK 承担证明签名，privacy CA 在两者间建立信任并保护隐私，实现匿名的可信证明。

• 硬件安全基线
• TPM 2.0 与 Secure Boot 的作用
• 提升系统安全基线

Windows 11 将 TPM 2.0 与 Secure Boot 设为硬件要求，目的是提升整个生态的安全基线。Secure Boot 保证系统只从可信、未篡改的引导链启动，防止 bootkit 在启动早期植入；TPM 2.0 提供硬件信任根，支持 BitLocker 磁盘加密（密钥绑定 PCR）、Windows Hello 凭据保护、VBS（虚拟化安全）与凭据/密钥的硬件保护。强制这些硬件使 Windows 默认具备可信引导、全盘加密与硬件密钥保护能力，显著提高对恶意软件与固件攻击的抵御能力。工程价值在于，统一硬件安全基线让安全的默认部署成为可能，降低整体攻击面。

TPM 2.0 + Secure Boot 提供硬件信任根与可信引导，是可信计算与全盘加密的基础，强制要求提高系统安全下限。

• IMA 的完整性度量
• EVM 的扩展验证
• 文件完整性保护

Linux IMA（Integrity Measurement Architecture）在文件被访问时计算其哈希（TPM 度量）并记录到度量列表，用于检测文件是否被篡改，支持本地/远程验证；EVM（Extended Verification Module）保护文件的扩展属性（如 IMA 哈希、安全 label），用密钥对元数据签名，防止攻击者同时篡改文件内容与对应的度量/属性。工程价值在于：IMA 提供文件完整性度量与远程证明，EVM 保证度量元数据本身不被篡改，二者结合使 Linux 系统能检测并报告文件被篡改，是可信计算的组成部分。

IMA 度量文件完整性，EVM 保护这些度量元数据，二者协同构建文件系统的完整性验证体系。

• PCR extend 操作
• 哈希累积
• 引导链度量

Measured Boot 通过 TPM 的 PCR extend 操作累积引导各阶段的度量。extend 的语义是：PCR 新值 = 哈希(PCR 旧值 + 新度量值)，即每个度量值被"累积"进 PCR，而非覆盖。引导时，固件（PCR0）、配置（PCR1）、引导加载器（PCR4）、配置（PCR5）、Secure Boot 状态（PCR7）等依次被度量并 extend 到对应 PCR。由于 extend 的累积性，PCR 最终值反映了整个引导序列的哈希链，任何阶段被篡改都会改变最终 PCR 值。工程语义在于，PCR 值是一个不可篡改的引导状态摘要，供 sealed 绑定与远程证明使用。

PCR extend 是"累积式哈希"，使 PCR 最终值精确反映引导链每一环节，任何篡改都会体现，是可信度量与证明的基础。

• TPM2_Quote 命令
• PCR 选择
• 远程证明

TPM2_Quote 是 TPM 2.0 的证明命令，用于对指定的一组 PCR 值生成签名证明。调用时，调用方选择要证明的 PCR（如 PCR0、PCR4、PCR7）并附上随机 nonce，TPM 用 Attestation Key（AK）对这些 PCR 值与 nonce 签名，输出 Quote 数据。远程证明中，验证方用 AK 公钥验证 Quote 签名，并核对 PCR 值是否与预期可信值一致，从而确认目标平台处于可信引导状态。nonce 防止重放。工程意义在于，TPM2_Quote 提供了硬件签名的、防重放的平台状态证明，是远程证明（如 attestation 服务）的核心接口。

TPM2_Quote 用 AK 对选定的 PCR 度量签名，验证方校验签名与 PCR 值即可远程确认平台可信状态。

• 事件日志记录
• 度量与 PCR 映射
• 审计与验证

TPM 2.0 事件日志（event log）记录了引导过程中每个被度量的事件（如固件、配置、加载器、内核的哈希与描述），这些事件按顺序对应 PCR 的 extend 运算。replay（重放）事件日志可重新计算 PCR 值，与 TPM 当前 PCR 值比对，验证日志是否真实、未被篡改。工程价值在于：事件日志把抽象的 PCR 数字映射到具体的软件组件，使验证者能"看到"引导链上具体是哪些组件、它们的哈希，从而定位是哪个组件被度量、是否可信，支持详细审计与远程证明的精细验证。

事件日志实现"PCR 值→具体组件"的映射，replay 校验日志真实性与 PCR 一致性，使证明可审计、可定位。

• local attestation report
• remote attestation 与 IAS
• 证明流程

SGX 的本地证明（local attestation）用于同一平台上的两个 enclave 之间互相验证身份，通过交换 report（包含 enclave 度量的签名结构）确认对方是可信的 enclave，从而建立安全通道。远程证明（remote attestation）用于向远端验证方证明 enclave 的真实性，流程是：enclave 生成 report，由 quoting enclave 用提供商密钥（Intel 的 provision/quoting key）签名后，通过 Intel Attestation Service（IAS）验证并返回验证结果，远端据此确认 enclave 运行的是预期代码。工程价值在于：本地证明使 enclave 间安全协作，远程证明使云端或其他主机能验证 enclave 可信性，支撑机密计算的可信协作。

local attestation 用 report 验证同机 enclave，remote attestation 通过 IAS 验证跨平台 enclave 真实性，二者支撑 SGX 可信协作。

• RMP 反向映射表
• 内存所有权与访问控制
• 完整性保护

AMD SEV-SNP 通过 Reverse Map Table（RMP）管理每个物理内存页的所有权与访问权限。RMP 记录每个物理页属于哪个 guest（或 hypervisor）及其权限，CPU 在每次内存访问时检查 RMP，确保 hypervisor 不能访问 guest 内存、guest 不能越权访问其他页。RMP 还支持页面验证（Page Validation）与完整性保护，防止恶意的 hypervisor 篡改 guest 内存或重放。工程价值在于，RMP 提供了硬件级的内存所有权与访问控制，加上完整性保护，使 SEV-SNP 能抵御恶意 hypervisor 的内存攻击，是 SNP 安全性的核心。

RMP 是页级所有权与访问控制表，配合完整性保护，防止恶意 hypervisor 访问或篡改 guest 内存，是 SNP 的信任基础。

• attestation report 内容
• VMID 与 measurement
• guest policy

AMD SEV-SNP 的 attestation report 是硬件生成的证明报告，包含 VMID（虚拟机标识）、measurement（guest 内存与固件的度量哈希）、guest policy（guest 声明的安全策略，如是否允许调试、是否允许迁移等）以及平台信任信息。工程价值在于：guest owner 可用 report 验证 guest 是否按预期镜像启动（measurement 匹配）、使用正确的 policy 与 VMID，从而确认 guest 环境可信且未被篡改或回滚。report 是远程证明与防回滚的关键，让 guest owner 在云上确认其 VM 运行在可信、正确配置的 SNP 环境中。

attestation report 以硬件签名证明 guest 的 VMID、度量与策略，owner 据此验证环境可信并防回滚。

• 单调计数器
• NV index
• 防回滚

TPM 提供单调计数器（monotonic counter）与 NV index（非易失存储索引），它们只能单调递增或按授权写入，会在 TPM 内部持久化。用于防重放时，可将计数器值作为协议的一部分（如版本号、一次性 nonce），若计数器被回滚，协议可检测到不一致。软件计数器存放在内存/磁盘，可被攻击者修改或回滚；而 TPM 计数器存储在受硬件保护的 NV 中，且受授权保护，无法被外部软件回滚或伪造，因此能提供可靠的防重放与防回滚基础。工程价值在于，TPM 计数器为设备提供不可篡改的单调状态，用于固件版本、许可证、防重放协议等。

TPM 计数器的硬件持久化与授权保护使其不可回滚，克服软件计数器可被篡改的缺陷，是可靠防重放的基础。

• TPM seal 磁盘主密钥
• PCR 绑定
• 恢复密钥机制

BitLocker/LUKS 可将磁盘主密钥（VMK）通过 TPM 密封（seal）到一组 PCR 值（如 PCR0/4/7），开机时 TPM 校验当前 PCR 与密封时一致则自动释放密钥，实现无密码开机（无需输入密码）。但当更换硬件（如换主板、换 CPU）或引导链被修改（如更新固件、被篡改）时，PCR 值或 TPM 状态变化，TPM 拒绝释放密钥，此时需要恢复密钥（recovery key）或额外的认证因素（如 PIN 或恢复密钥文件）来解锁磁盘。工程价值在于：TPM 绑定提供"系统可信才自动解锁"的安全性与便利性，同时保留恢复密钥作为硬件变更或引导变更时的应急手段。

TPM seal 使磁盘密钥在可信状态自动释放，硬件变更或引导篡改导致 PCR 变化时需恢复密钥兜底，兼顾安全与可用。

• Keystone 的成熟架构
• Security Monitor（SM）
• runtime 与 enclave

Keystone 是 MIT 主导的基于 RISC-V 的开源 enclave 框架，其架构分为多个层次。Security Monitor（SM）是运行在 M-mode（机器模式）的不可信 OS 之下的安全监视器，负责管理 enclave 的内存与执行（创建/销毁 enclave、管理 PMP 隔离），是信任边界；enclave runtime 运行在被隔离的 enclave 内，为应用提供运行时环境（如内存管理、系统调用接口）；应用与 enclave 通过调用接口交互。SM 利用 RISC-V 的 PMP（物理内存保护）实现隔离，attestation 由 SM/runtime 提供测量。工程结构上，SM 提供底层可信原语，runtime 提供高层 API，使开发者可构建可信 enclave 应用。

Keystone 的 SM（M-mode 安全监视器）+ runtime（enclave 内运行时）分层，SM 负责隔离与可信，runtime 提供应用接口，是开源可定制的 TEE。

• RISC-V 开源硬件
• Keystone 的 TEE 提供
• 生态推动

Keystone 在 RISC-V 硬件安全演进中的工程意义在于：它为开源 RISC-V 生态提供了可用的可信执行环境（TEE）框架。RISC-V 是开放指令集，Keystone 以开源方式实现 enclave 隔离，使研究者、开发者能自由修改、审计与定制安全机制，推动安全硬件研究的普及。相比 Intel SGX/ARM CCA 等封闭实现，Keystone 让 RISC-V 平台具备可验证、可扩展的机密计算能力，并催生 RISC-V 安全硬件标准（如 PMP、指针认证）的演进。工程意义在于，Keystone 为 RISC-V 生态奠定可信计算基础，加速安全硬件与开源 TEE 的成熟。

Keystone 为开源 RISC-V 提供可用 TEE，推动安全硬件开源化与 RISC-V 生态演进，是 RISC-V 安全的关键推动者。

• RMM 的角色
• Realm 生命周期管理
• type-2 hypervisor 性质

ARM CCA 中，RMM（Realm Management Monitor）是运行在 Root World 的固件，作为执行 Realm 的运行时，负责 Realm 的创建、销毁与生命周期管理。RMM 在一定程度上类似 type-2 hypervisor，因为它管理 Realm（guest）的地址空间、执行状态与资源，但它的职责更聚焦于 Realm 的安全隔离与证明，而非普通 VMM 的完整虚拟化。RMM 向 Normal World 的 hypervisor 提供接口（如 RMM 规范调用），使 hypervisor 能请求创建 Realm，但无法访问 Realm 内部。工程价值在于，RMM 作为受信任固件，将 Realm 生命周期与安全隔离集中管理，是 CCA 安全边界的关键。

RMM 作为类 type-2 hypervisor 的固件管理 Realm 生命周期与隔离，为 hypervisor 提供不可窥探的 Realm 执行环境。

• 各技术的威胁模型
• 隔离对象
• 信任边界

TrustZone 的威胁模型是"安全世界（Secure World）与普通世界（Normal World）"的隔离，主要保护富 OS 之上的安全组件（如 TEE 应用），但普通世界 OS 与安全世界之间有相对固定的信任边界。ARM CCA 的 Realm 威胁模型是"在不可信 hypervisor（Normal World）之上运行机密工作负载"，将整个 VM（Realm）与 hypervisor、OS 隔离，hypervisor 被视为不可信。AMD SEV-SNP 的威胁模型类似，将 guest VM 与不可信 hypervisor 隔离，并通过 RMP 防篡改。差异在于：TrustZone 侧重双世界隔离（安全组件），CCA 与 SEV-SNP 侧重 VM 级机密计算（防恶意 hypervisor），后两者面向云多租户的机密计算场景。

TrustZone 保护安全组件，CCA/SEV-SNP 保护整个 VM 免受不可信 hypervisor 攻击，威胁模型层级不同。

• GPT bitmap 粒度保护
• 内存访问控制
• 完整性保护

ARM CCA 使用 Granule Protection Check（GPT）通过一个 bitmap 记录每个内存粒度（granule）所属的世界（Realm、Secure、Normal 等）。每次内存访问时，硬件检查 GPT 位图，确保只有拥有该 granule 访问权的世界才能访问，从而阻止 Normal World 的 hypervisor 访问 Realm 内存，也阻止 Realm 越权访问其他内存。GPT 提供的隔离是硬件强制的，配合 Realm 的完整性保护（检测内存篡改），防止恶意 hypervisor 读写或修改 Realm 数据。工程价值在于，GPT bitmap 是 CCA 内存隔离的硬件基础，支撑 Realm 的机密性与完整性。

GPT bitmap 按粒度记录内存归属并强制访问控制，配合完整性保护，是 CCA 内存隔离与防篡改的核心。

• PMP 物理内存保护
• 内存区域隔离
• 硬件访问控制

Keystone 使用 RISC-V 的 PMP（Physical Memory Protection）实现 enclave 内存隔离。PMP 允许为地址空间区域配置访问权限（读/写/执行），并区分特权模式。Keystone 的 Security Monitor 将 enclave 的内存区域配置为仅 enclave 可访问，普通 OS/应用（S/U 模式）无权访问，从而在硬件层面隔离 enclave 内存。PMP 检查在每次内存访问时强制执行，即使 OS 被攻破也无法读写 enclave 内存。工程价值在于，PMP 是 RISC-V 硬件提供的内存隔离原语，Keystone 利用它实现轻量、可定制的 enclave 隔离，无需额外硬件。

Keystone 用 RISC-V PMP 配置 enclave 内存访问权限，实现硬件强制隔离，是开源 TEE 的隔离基础。

• enclave 度量
• runtime 度量
• 链式证明

Keystone 的 attestation 通过链式证明报告 enclave 状态。它度量多个组件：runtime（运行时）本身的哈希、enclave 应用代码的哈希等，这些度量被记录并用于构造证明。证明时，Security Monitor 提供对 enclave 状态的签名度量，验证方通过校验这些度量（enclave measurement + runtime measurement）确认 enclave 运行的是预期代码、runtime 未被篡改。链式证明将 runtime 与 enclave 的度量串联，形成"SM→runtime→enclave 应用"的可信链，使验证方能在不信任 OS 的前提下确认 enclave 的完整性。

链式证明将 runtime 与 enclave 度量串联，形成可验证的可信链，使远程方确认 enclave 运行预期代码。

• PKCS#11 标准接口
• 会话与密钥生命周期
• 签名/验证操作

PKCS#11 是 HSM 的标准化接口。C_Initialize 初始化 HSM 库（建立与设备的连接）；C_OpenSession 打开一个会话（会话是执行操作的上下文，可设置登录状态）；C_GenerateKeyPair 在 HSM 内生成公钥/私钥对（私钥不离开设备）；C_Sign 使用私钥在 HSM 内执行签名操作；C_Verify 使用公钥验证签名。这些 API 使应用通过统一接口使用 HSM 的密钥管理、签名与验证功能，而私钥始终在硬件内。工程价值在于，PKCS#11 提供跨厂商的标准接口，应用可无缝集成不同 HSM，实现密钥内操作与安全签名。

PKCS#11 以 C_ 系列接口封装 HSM 的初始化、会话、密钥生成、签名与验证，私钥内操作是其安全核心。

• USB 接口（USB-A/USB-C）
• form factor 形态
• 部署场景

YubiHSM2 采用 USB 接口（USB-A/USB-C），以小型 USB 插件形态存在，适合直接插入服务器、边缘设备或 USB hub。工程部署上，其小巧形态便于在数据中心服务器上即插即用（无需占用 PCIe 槽位），适合边缘设备、开发环境、测试环境与小规模生产；通过 yubihsm-connector 可将其作为网络可访问的 HSM 服务使用。但单机 USB 形态缺乏冗余与高可用，适合中低负载场景；大规模高可用关键场景仍需专用机架式 HSM。工程取舍在于，YubiHSM2 的 USB 形态兼顾低成本、易部署与可移植性，适合边缘与中小规模。

USB plug form factor 便于数据中心/边缘即插即用和便携，通过 connector 网络化，适合低成本中小规模部署。

• KMIP 标准协议
• 密钥管理互操作
• 多厂商协同

KMIP（Key Management Interoperability Protocol）是 OASIS 标准，用于密钥管理对象（密钥、证书、模板）的创建、存储、使用与销毁，提供标准化的密钥管理接口。工程价值在于：KMIP 让不同厂商的 HSM、KMS 与应用之间实现密钥管理互操作，应用无需针对特定厂商 API 定制，即可通过统一协议管理跨厂商的密钥（如 AWS KMS、Azure Key Vault、IBM 等支持 KMIP）。这降低了供应商锁定，支持多厂商密钥管理系统的集成，是大型企业与多云环境中密钥管理标准化的关键。

KMIP 标准化密钥管理接口，实现跨厂商 HSM/KMS 互操作，减少供应商锁定，是密钥管理标准化的基础。

• ARM 处理器对 Meltdown 的暴露
• Cortex-A75/A76 影响
• Apple A 系芯片

Meltdown 主要影响采用乱序执行且未做权限检查隔离的 Intel 及部分 ARM 处理器。ARM Cortex-A75 等部分乱序执行核心被证实受 Meltdown 影响（ARM 发布了补丁与说明），因为它们同样存在"先执行后检查权限"的乱序执行行为；较新的 Cortex-A76 及 Apple A 系列芯片经研究被认为对 Meltdown 免疫（或影响极低），因为其具体实现可能已通过类似隔离机制或微架构设计规避。工程影响在于，ARM 处理器同样需要评估与缓解瞬态执行漏洞，但不同厂商/核心的实现差异导致暴露程度不同。

乱序执行是 Meltdown 前提，ARM Cortex-A75/A76 受影响，Apple A 系相对免疫，体现微架构实现差异对漏洞的影响。

• RSB 返回栈缓冲区
• RSB stuffing 填充
• microcode 更新

Spectre 变体可利用 RSB（Return Stack Buffer）被污染：RSB 缓存返回地址，攻击者可诱导深层调用使 RSB 预测错误的返回目标，从而在投机执行中泄漏数据。RSB stuffing（RSB 填充）是在特权级切换（如系统调用、VM 切换）时，用无害的返回地址填充 RSB，防止跨特权/跨上下文污染。在 Skylake/Kaby Lake 等 CPU 上，通过 microcode update 提供 RSB 填充或相关修复，配合内核的 RSB stuffing 代码，缓解 RSB 相关的 Spectre 攻击。工程价值在于，microcode 更新与操作系统补丁协同，修补 RSB 污染的投机执行漏洞。

RSB stuffing 在特权切换时填充无害返回地址，防止 RSB 污染诱导投机执行，microcode 更新提供硬件/微码层面的缓解。

• PREFETCH 指令
• 瞬态执行泄漏
• AMD Zen 影响

Augury（CVE-2022-23824）是影响 AMD Zen1/Zen2 处理器的瞬态执行漏洞，利用 PREFETCH（预取）指令的瞬态执行行为泄漏数据。PREFETCH 指令本用于将数据预取到 cache，但在某些情况下，预取操作会基于瞬态/未验证的数据进行地址计算，攻击者可通过精心构造的预取指令序列，经 cache 侧信道推断出敏感数据。修复通过 microcode 更新和软件缓解执行。工程影响在于，该漏洞展示了即便预取这类"非计算"指令也可能成为瞬态执行泄漏通道，需通过微码与软件协同缓解。

Augury 利用 PREFETCH 指令的瞬态执行经 cache 侧信道泄漏数据，是 AMD 特定核心的瞬态执行漏洞。

• register rename 机制
• 投机执行泄漏
• Zen2 影响

Zenbleed（CVE-2023-20593）是影响 AMD Zen2 处理器的瞬态执行漏洞。它利用寄存器重命名（register rename）与投机执行的交互：在特定指令序列下，CPU 可能错误地将一个寄存器重命名对应到另一个的物理寄存器的瞬态数据，导致投机执行时泄漏原本应被隔离的寄存器数据（如浮点寄存器、向量寄存器中的敏感数据）。攻击者可通过构造的指令诱导投机执行，经侧信道恢复寄存器内容。修复通过 microcode 更新（如加载特定 MSR 值）或软件缓解。工程影响在于，寄存器重命名的实现缺陷可能引发跨上下文数据泄漏。

Zenbleed 利用 register rename 与投机执行的缺陷泄漏寄存器数据，是 Zen2 核心的瞬态执行漏洞，需 microcode 修复。

• HMAC session 授权
• policy session 授权
• 需 policy 的场景

TPM 2.0 提供两种授权方式。HMAC session 使用预共享的授权值（如密码/PIN）通过 HMAC 验证授权，简单高效，适合"知道秘密即可操作"的场景。policy session 基于一组 policy 命令（如 TPM2_PolicyPCR、TPM2_PolicyCommandCode、TPM2_PolicySecret）动态构建授权条件，适合需要"复合条件"才授权的场景。当授权条件依赖系统状态（如 PCR 值必须匹配、多因素、特定命令等）时，必须用 policy session，因为 HMAC 只能表达"持有秘密"，无法表达"系统处于可信状态"。例如 sealed object 绑定 PCR 时，用 policy session 表达"PCR 匹配才允许 unseal"，这正是 policy 的典型应用。

HMAC session 表达"持有秘密"，policy session 表达"满足复合条件（如 PCR 绑定）"，故 PCR 绑定等状态相关授权必须用 policy。