Intel SGX 退场，Diamond Rapids 成为最后一代支持 Enclave 的 Xeon

Intel 已确认将逐步淘汰 Intel SGX，这意味着其计划于 2027 年推出的 Diamond Rapids Xeon 平台将成为最后一代采用该 Enclave 技术的产品。

这一决定为 Intel 的机密计算战略画上了重要一章。Software Guard Extensions，即 SGX，可将选定的应用代码和数据隔离在由硬件保护、称为 Enclave 的内存区域中。Intel 未来将把投资转向 Trust Domain Extensions，即 TDX；后者则隔离完整的虚拟机。

这项变化并非一次常规功能退役。SGX 为开发者提供了狭窄的安全边界，但要求采用专门的应用设计。TDX 则保护更大的环境，同时适配云服务商和企业基础设施团队已广泛使用的虚拟机模型。

Intel 表示，现有 SGX 平台将在 2030 年代初之前持续获得支持和安全更新。因此，客户仍有时间评估迁移路径。不过，新的机密计算项目如今面临更明确的架构选择：围绕 TDX 构建、接受 SGX 有限的未来，或考虑其他硬件平台。

Intel SGX 将在 Diamond Rapids 之后开始退场

Diamond Rapids 将为 Xeon 最后保留一代 SGX，但 Intel 的长期路线图如今属于 TDX。

Intel 于 2026 年 10 月 9 日披露了这一决定。该公司表示，Diamond Rapids 将是最后一个包含 SGX 的 Xeon 平台。Intel 计划于 2027 年推出这一处理器家族。

该公司不会立即禁用现有 Enclave，也不会终止当前支持。其机密计算路线图承诺将在 2030 年代初之前提供安全更新和平台支持。这一时间表为受监管企业和基础设施供应商提供了数年规划期。

Intel 最早于 2017 年将 SGX 引入数据中心处理器，后来又通过 Sapphire Rapids 将该技术带入主流 Xeon 服务器平台。SGX 成为了在应用主动处理数据期间保护数据的最知名方案之一。

传统加密保护静态数据或在网络中传输的数据。机密计算则通过将工作负载置于由硬件强制执行的可信执行环境中，保护使用中的数据。主机管理员、Hypervisor 或相邻工作负载不应能直接访问受保护内存。

SGX 在应用层实现这一理念。开发者选择敏感函数和数据，然后将其置于 Enclave 中。操作系统和 Hypervisor 则位于可信边界之外。

TDX 改变了隔离单元。它创建一个信任域，即一台与主机及其他虚拟机隔离、受硬件保护的虚拟机。该环境内的应用通常无需再被拆分为 Enclave 与非 Enclave 组件。

这一差异解释了 Intel 此次公告的重要性。该公司选择了部署更简便、保护边界更广的方案，而非 SGX 更小、更专业化的边界。

Intel 还表示，市场正日益围绕虚拟机隔离形成共识。主要公有云已围绕虚拟机、镜像、编排层和成熟的管理工具运行。TDX 比应用 Enclave 更直接地适配这些系统。

路线图的最终性带来了即时的规划影响。组织仍可购买、部署和维护支持 SGX 的系统，但不应再假设未来 Xeon 世代会保留相同的应用架构。

Diamond Rapids 现在承担两种角色：它既是 Intel 下一代高端 Xeon 平台，也是仍依赖 SGX 的客户的最后一座桥梁。

对于硬件更换周期较长的组织而言，这座桥梁将很有价值。但它并未改变整体方向。Intel 已公开将其未来机密计算工作归于 TDX。

Intel 为何此时从 SGX 转向 TDX

这一转变反映了运营现实：保护整台虚拟机比围绕 Enclave 重新设计每个应用更容易被采用。

SGX 和 TDX 防御的威胁存在重叠，但各自带来的责任不同。SGX 能够构建较小的可信计算基，即安全所必须信任的代码和组件。更小的边界可以减少暴露给攻击者的软件量。

这一优势伴随着工程成本。开发者必须识别敏感逻辑，管理受保护与未受保护代码之间的切换，并处理 Enclave 内存限制。他们还必须围绕 Enclave 模型设计证明、密钥交付、错误处理和软件更新。

对于加密服务、身份系统、金融处理或持有特别敏感机密的应用而言，这些要求或许合理。但当组织希望保护数千个普通工作负载时，其合理性便更难成立。

TDX 提供了不同的取舍。基础设施团队可以将操作系统、应用栈及配套服务置于机密虚拟机中。现有工作负载所需的应用专属改动更少。

Intel 将 TDX 描述为更具可扩展性和灵活性、总运营成本更低的方法。其SGX 过渡指南明确将易用性和部署灵活性列为转型原因。

云采用进一步强化了这一理由。Microsoft Azure、Google Cloud、IBM Cloud、Alibaba Cloud 和 Volcano Cloud 均已提供基于 Intel TDX 的服务。Red Hat、Canonical 和 VMware 也在为企业和私有云环境推进支持。

周边软件与处理器功能同样重要。机密计算必须与镜像创建、密钥管理、策略执行、编排、监控和远程证明相连接。

证明机制使远程一方能够在释放密钥前，验证受保护环境的身份及预期状态。无法融入现有部署系统的技术，可能始终只是专业化的安全功能。

数据主权是另一项驱动因素。法规和内部政策越来越关注谁能够访问信息，而不仅是信息存放在哪里。硬件隔离可以限制云管理员或遭入侵的主机软件接触信息。

Intel 将 TDX 定位为这类部署的技术控制手段。即使底层基础设施属于另一家组织，机密虚拟机也能保持其内存隔离。

代理式 AI 带来了较新的需求来源。AI 代理可以读取企业记录、调用外部服务、更新系统，并与其他代理交换信息。因此，其执行环境可能汇集凭据、专有数据和敏感的中间结果。

仅保护一个经过谨慎挑选的函数，并不总是适合这类工作负载。AI 代理可能依赖运行时、模型接口、检索服务、工具集成和多个软件库。隔离完整环境可能更为实际。

这并不意味着 TDX 对每一种安全问题都天然优于其他方案。它意味着，TDX 更契合 Intel 预计将在机密云和企业计算中占主导地位的部署模型。

Intel SGX 的退场正式确认了这一押注。Intel 不再无限期资助两种不同的隔离模型，而是将路线图集中在拥有更广泛基础设施支持的一种模型上。

Intel SGX 与 TDX 是一种取舍，并非直接升级

TDX 通过扩大可信边界来简化部署，而 SGX 则要求投入更多工程工作以保持该边界较小。

Intel SGX 与 TDX 最重要的区别在于粒度。SGX 隔离选定的代码和数据。TDX 隔离整台虚拟机，包括其客户操作系统和应用依赖项。

这种扩大后的范围能够让 TDX 更易使用，但也意味着更多软件位于可信计算基之内。受保护客户环境中的漏洞，仍可能危及该客户环境可访问的数据。

SGX 让安全团队能更精确地控制哪些内容进入可信区域。Enclave 可以排除操作系统、大多数库以及无关的应用组件。当开发者正确实现时，这种结构支持严格的隔离。

但其工程负担十分可观。为普通操作系统环境编写的应用可能依赖系统调用、动态内存、文件、网络和大型软件框架。仅将其敏感组件迁入 Enclave，需要审慎拆分。

库操作系统可通过在 Enclave 内部或周边提供熟悉的操作系统功能来降低这一工作量。但它们仍会带来架构决策、兼容性测试和额外的可信组件。

TDX 将更多问题转移给基础设施。团队可以将应用打包为机密虚拟机，并通过熟悉的云工具进行管理。这支持在现有软件组合中更快采用。

因此，安全比较取决于工作负载。

可信边界

• SGX：保护 Enclave 内选定的应用函数和数据。

• TDX：保护整台虚拟机免受主机环境影响。

应用改动

• SGX：通常需要代码拆分、具备 Enclave 意识的开发方式，或兼容的库操作系统。

• TDX：可在有限应用改动下运行许多现有工作负载。

运营模式

• SGX：围绕单个 Enclave 进行保护和证明。

• TDX：适配虚拟机镜像、云端配置和基础设施编排。

安全责任

• SGX：让更多主机软件处于可信边界之外，但将额外的设计责任交给应用开发者。

• TDX：将主机排除在可信边界之外，但要求信任更多客户环境软件。

迁移也远比替换一项处理器设置复杂。Intel 的过渡文档将 SGX 应用分为不同架构模式，每种模式都可能通向不同的目标方案。

已经通过库操作系统运行的应用，或可在中等改动下迁入机密容器或 TDX 虚拟机。直接基于 SGX 开发套件构建的软件，则可能需要更深入的重新设计。

一些应用可能会在未来数年继续保留其 Enclave 架构。另一些应用则可能将敏感函数拆分为独立服务。团队也可以在分阶段迁移期间，将现有 SGX 工作负载置于更广泛的机密环境中。

远程证明也带来另一项差异。SGX 可以证明 Enclave 代码的身份和度量值。TDX 则证明信任域及其启动环境的状态。组织必须调整用于决定何时释放密钥或接受受保护结果的策略。

团队不应假设这些度量值具有完全相同的含义。其验证服务、参考值、证书流程和更新规则都需要审查。

其结果并不是一个简单的 Intel TDX 迁移按钮，而是一项涉及应用所有者、平台工程师、安全团队和合规专家的架构计划。

TDX Connect 瞄准 CPU 与加速器之间的薄弱环节

Intel 的路线图必须保护 CPU 内存之外的数据，因为机密 AI 日益需要在处理器、GPU 与其他设备之间传递信息。

机密虚拟机可以将其 CPU 内存与主机隔离。但这种保护并不会自动保护每一次向加速器或外围设备的数据传输。

这一缺口对 AI 至关重要。受保护的工作负载可能将提示词、模型参数、嵌入向量或中间结果从 CPU 环境发送至 GPU。在传输过程中，数据可能离开原有的可信边界。

Intel 计划通过 TDX Connect 扩展 TDX。TDX Connect 是一种面向受保护设备通信的可信输入输出架构，目标是在机密虚拟机与分配给它的硬件交互时维持隔离。

Intel 此前已介绍过针对部分 CPU 到设备传输的、基于软件的加密中转缓冲区。中转缓冲区会先将加密数据经由主机可访问的内存传递，再由目标端解密。这提供了一种可行的桥接方式，但可能带来额外开销。

TDX Connect 旨在支持更直接、由硬件支撑的传输路径。Intel 表示，未来开发还将涵盖更强的证明机制和后量子密码学。该公司尚未公布各项增强功能的确切可用日期。

这一缺失的时间表很重要。Intel 的战略方向已经明确，但客户仍需要产品层面的细节。他们需要了解哪些处理器、平台、设备、固件版本和云服务将支持各项能力。

Intel 正与 Nvidia 合作，协调 CPU 与 GPU 之间的机密计算。Nvidia 已在部分加速器上提供受保护执行功能，包括内存加密和证明。该联合模式旨在为整个 AI 系统建立连续的信任链。

但这条信任链在技术上仍极具挑战。CPU、加速器、固件、设备分配系统、虚拟机监控器和证明服务必须对受保护环境达成一致。任一层面的薄弱点都可能降低对整个部署的信心。

Apple 提供了一个可见的更广泛发展方向案例。其 Private Cloud Compute 设计结合专用硬件、可验证软件和外部审查机制，以保护云端处理。Intel 表示，其与 Google Cloud 的一项扩展合作在 Xeon 基础设施上使用了 TDX 信任域。

这一案例表明，仅靠硬件隔离并不足够。客户还需要关于软件身份、更新控制、日志记录、密钥释放和管理员访问的证据。

智能体系统让这些问题更加紧迫。一个自主服务可能持有数据库、电子邮件系统、源代码仓库或业务应用的凭据。若保护了模型调用却暴露了工具凭据，仍会留下关键缺口。

机密虚拟机可以将智能体运行时及其连接器置于同一隔离环境中。可信 I/O 随后可帮助保护其与加速器及分配设备之间的交换。

这一模式支撑了 Intel 推广 TDX 的论点，同时也扩大了客户必须验证的范围。安全如今依赖于一个相互连接的系统，而非单一的飞地边界。

TDX 路线图将由实施细节、独立测试和云端可用性来评判。计划中的功能清单无法替代可部署的硬件和可复现的安全证据。

安全记录要求保持谨慎

SGX 和 TDX 都无法消除软件漏洞、侧信道攻击，或独立安全审查的必要性。

Intel 并未将 SGX 退役归咎于安全缺陷。该公司反而强调了采用情况、可扩展性、部署简易性，以及行业对虚拟机隔离的偏好。

不过，可信执行环境的历史需要被谨慎解读。研究人员已披露影响机密计算技术的侧信道攻击、权限提升路径以及与证明相关的弱点。

SGX 曾面临数个备受关注的攻击家族。一些攻击利用推测执行或微架构行为来推断受保护信息。另一些则针对实现错误、软件接口，或 Intel 所定义威胁模型之外的假设。

TDX 同样需要接受广泛审查。Intel 表示，其发布前研究包含四人年的安全分析工作。这项工作发现了数十个漏洞，并带来了十余项架构或纵深防御改进。

Google 后来与 Intel 合作评估 TDX 1.5 功能，包括实时迁移和信任域分区。这项研究发现了漏洞，同时也推动了修复和加固工作。

这一过程对于复杂安全技术而言是正常的。它并不能证明某个平台不安全，但说明了为何对于“完全保护”的说法应保持怀疑。

机密计算能够缩小某些基础设施风险，但并不能防御每一种恶意应用、遭入侵的依赖项、被盗凭据或存在缺陷的访问策略。受保护环境仍可能安全地执行有害或易受攻击的软件。

威胁模型与营销语言之间的区别至关重要。TDX 旨在保护客户机免受不可信或遭入侵的主机影响。它并不会自动让该客户机内部的每一个组件都变得可信。

证明可以确认测量结果是否符合预期参考值，但无法判断被测量的应用程序是否包含逻辑错误。它还依赖可靠的验证服务以及经过审慎管理的参考策略。

实时迁移带来了另一项挑战。云运营商需要在不暴露内存或破坏信任的情况下，在主机之间移动受保护的虚拟机。这项能力引入了研究人员必须检查的协议、密钥、状态转换和额外代码。

设备访问增加了更多复杂性。可信 I/O 必须在保持设备性能和可管理性的同时，阻止主机检查或篡改受保护流量。加速器固件和设备安全也因此成为实际信任体系的一部分。

后量子密码学也带来类似问题。Intel 已将其列为未来投资领域，但这一标签可能涵盖不同的算法和系统组件。客户需要知道具体会发生哪些变化，以及何时发生。

因此，安全团队应将 Intel TDX 迁移视为一次新的评估，而不是 SGX 保障案例的自动延续。现有的威胁模型、控制措施和合规证据都需要修订。

他们还应审查恢复流程。硬件证明系统依赖证书、签名基础设施、吊销机制和可信服务。故障或策略错误可能导致合法工作负载无法获得其机密信息。

供应商多样性同样值得考虑。AMD 提供了带安全嵌套分页的安全加密虚拟化，通常称为 SEV-SNP。它同样能够保护虚拟机免受主机环境部分组件的影响。

AMD SEV 文档介绍了内存加密、完整性保护和客户机证明。云服务提供商可以同时提供 AMD 和 Intel 的机密虚拟机选项，为采购方提供架构和供应选择。

Nvidia 的机密计算平台将保护扩展至受支持的 GPU。Arm 的 Confidential Compute Architecture 则面向 Arm 环境中的受保护执行。每种设计在成熟度、可用性和威胁假设方面各不相同。

因此，Intel 的竞争不止于处理器性能。它必须通过文档、独立审查、云端部署和可预测的安全维护来赢得信任。

Intel SGX 的逐步退出简化了 Intel 的路线图，却没有简化客户必须回答的安全问题。

SGX 客户需要逐工作负载制定迁移计划

最稳妥的应对方式是立即盘点 SGX 依赖关系，然后将每个工作负载与其所需的保护边界相匹配。

组织应从发现工作开始。他们需要识别那些直接调用 SGX 接口、依赖具备飞地感知能力的框架，或使用由 SGX 支撑但未显式暴露该依赖关系的服务的应用。

托管服务尤其值得关注。企业可能通过数据库、区块链服务、密钥管理产品或机密分析平台依赖 SGX。客户本身未必直接运营这些飞地。

随后，每个工作负载都需要一份安全档案。团队应记录受保护资产、预期攻击者、可信组件、证明流程、性能约束和监管义务。

该档案决定 TDX 是否是可接受的替代方案。围绕最小飞地边界设计的工作负载，在迁移到更大的客户机环境后，未必能获得等效的隔离。

其他应用会更容易迁移。主要使用 SGX 来保护完整服务免受云管理员影响的软件，可能很适合机密虚拟机。TDX 可以在保留硬件支撑的主机隔离能力的同时，减少定制代码。

Intel 的迁移指南列出了若干可选路径，包括迁移库操作系统工作负载、重新设计 SGX 开发套件应用，以及采用机密容器。

机密容器将容器工作流与硬件隔离的虚拟机结合起来。容器接口保持熟悉，而信任域则将工作负载与主机分隔开来。这可能适合已经使用 Kubernetes 和 Kata Containers 的团队。

测试不应只覆盖应用启动。团队必须验证证明、机密信息释放、升级、备份、恢复、可观测性、事件响应和主机间迁移。

性能同样需要测量。TDX 环境保护的是更大的软件栈，其内存处理方式也不同于 SGX 飞地。工作负载行为可能因处理器、云配置和设备路径而变化。

组织不应将所有决策都拖延到 SGX 支持结束之后。在受监管环境中，硬件采购、应用重构、认证和供应商批准可能需要数年时间。

他们也应避免不必要的紧急迁移。Intel 已承诺提供较长的支持周期，且 Diamond Rapids 还将提供又一代支持 SGX 的产品。在团队验证替代方案期间，现有系统仍可能继续适用。

最强的迁移计划会同时保留旧环境和新环境的证据。安全团队应比较实际的可信计算基，而不仅仅是硬件功能的名称。

采购合同可能需要更新。采购方应询问云服务和软件供应商，其 SGX 服务将维持可用多久。他们还应要求提供 TDX 支持、证明接口和可信 I/O 的时间表。

开发人员需要明确的责任归属。基础设施团队可以配置 TDX 实例，但应用团队仍控制依赖项、机密信息和授权。机密计算并不会消除这些责任。

这一决策也会影响未来架构。新的 SGX 项目应说明，为何在硬件路线图日益收窄的情况下，飞地仍然必要。新的 TDX 项目则应说明，为何完整客户机是可接受的安全边界。

因此，Intel TDX 迁移应作为基于风险的工作负载组合来推进，而不是进行普遍重写。一些工作负载可以提前迁移，另一些则应利用剩余的 SGX 支持窗口。

在 Intel 选择 TDX 后需要关注什么

三个信号将显示 Intel 能否将更清晰的路线图转化为可信的机密计算平台。

第一个信号是 Diamond Rapids 的详细供货情况。Intel 已将这款 2027 年处理器定位为最后一代 SGX 产品，但客户需要明确的平台时间表和产品覆盖范围。

这些细节将决定实际迁移的时间窗口。覆盖广泛且提供稳定 SGX 支持的 Diamond Rapids 产品组合将保留更多选择空间。有限的供货则会加大采用专用 enclave 部署的客户所面临的压力。

第二个信号是可部署的 TDX Connect 支持。Intel 已将可信 I/O 描述为机密 AI 和连接设备工作负载的重要扩展。采购方需要已出货的硬件、兼容的加速器、固件指导以及独立验证。

这一信号将强化或削弱 Intel 关于 agentic AI 的论点。广泛且经过测试的支持将帮助 TDX 保护更多 AI 处理路径。延迟则会使软件层面的变通方案和碎片化的信任边界继续存在。

第三个信号是云服务和软件供应商的迁移行为。Azure、Google Cloud、IBM Cloud、Alibaba Cloud、Red Hat、Canonical 和 VMware 已经构成 TDX 生态系统的一部分。它们的服务路线图将显示客户是否会跟随 Intel 的方向。

关注新的机密虚拟机区域、更强的证明工具、机密容器支持，以及从 SGX 支持的服务迁移的文档化方案。同时也要留意供应商是否会为专用产品继续保留 SGX。

竞争对手的动态提供了另一项有用的基准。AMD SEV-SNP 更广泛的采用，或更强的加速器级替代方案，将表明市场支持机密虚拟机，而无需向单一供应商靠拢。

最大的未知因素在于安全粒度。TDX 的运维简洁性很有价值，但它并未重建 SGX 狭窄的 enclave 边界。具有严格隔离要求的客户必须判断，更宽泛的信任域是否可以接受。

Intel 正在给予这些客户时间，但并非无限期的路线图。Diamond Rapids 将是 Xeon 上计划支持 SGX 的最后一站。此后的每一代 Intel 服务器都将推动新的部署转向 TDX。

对开发者和企业采购方而言，下一步行动很明确：盘点 SGX 在何处保护生产系统，记录每个 enclave 存在的原因，并测试 TDX 是否能够保留所需的保障。

不要将退役日期视为发令枪。应利用支持窗口比较各种架构、验证证明策略，并要求供应商提供具体的部署承诺。

Intel 逐步淘汰 SGX，归根结底是在运营规模与 enclave 专业化之间投票选择前者。这一选择能否成功，将取决于安全证据、生态系统执行力以及真实迁移路径的质量。