VPS 机密计算：AMD SEV-SNP 与 Intel TDX

VPS 上的机密计算实际意味着什么

VPS 上的机密计算是指，处理器使用虚拟机监控程序永远无法获取的密钥加密虚拟机内存。因此，物理服务器的运营方无法读取服务器正在处理的数据。如今销售的 VPS 几乎没有采用这种方式。对于普通 VPS，提供商的虚拟机监控程序可以读取客户机内存中的每个字节；而加密磁盘并不能改变这一点。

公开发布的指南面向两类用户，VPS 租户不属于其中任何一类。Canonical 的机密计算资料要么介绍如何在云服务商平台上启动镜像（例如特定的 Azure 规格或 Google Confidential VM），要么介绍如何将自有硬件配置为机密虚拟机主机。这两类资料都假定你是云服务商，或是主机运营方。它们都没有说明：租用 4 GB VPS 的用户，能否在自己已经付费使用的服务器上获得这项能力。应先明确威胁模型，因为所有实际结论都取决于此。

谁现在可以读取您的 VPS 内存

您的 VPS 是一个来宾系统。其他组件负责创建它、为其分配内存，并将其调度到物理核心上。大多数 Linux VPS 托管服务使用 KVM。此时，来宾系统的 RAM 是主机上 QEMU 进程持有的普通匿名内存。主机上的 root 用户可以像读取其他进程一样读取该进程的内存，可以通过 /proc/<pid>/mem 完成，也可以使用 virsh dump 将来宾系统的完整内存映像写入文件。您的虚拟机内部无法阻止这种操作，也无法检测这种操作，因为执行读取的一方控制着负责进行检测的那一层。

这不是某个服务提供商的缺陷，而是虚拟化的工作方式。管理程序的职责是管理来宾系统的内存，因此它能够读取该内存是这一设计的直接结果。这也是 VPS 托管是否适合真实工作负载 取决于运营方的操作规范和员工访问控制，而不是技术本身的原因：单靠技术无法限制运营方。基于容器的套餐隔离性更弱，因为 LXC 或 OpenVZ 来宾系统与主机共享内核，主机无需生成内存转储即可读取您的进程。在比较价格之前，应当理解这一差异；KVM、Xen 和 LXC 虚拟化之间的区别 就在于此。

为什么全盘加密无法解决这个问题

VPS 上使用全盘加密仍然有价值，但它无法解决这里的问题。LUKS（Linux unified key setup）在数据块写入磁盘时对其加密，在读取时对其解密。为此，只要卷处于挂载状态，卷密钥就必须一直保留在内核内存中。因此，密钥在内存中，传输中的明文数据也在内存中，而内存正是主机可以读取的内容。

静态数据加密确实能提供实际保护：离开机房的磁盘仍然无法读取。返还给供应商的故障磁盘受到保护。有人遗忘的已分离备份卷也受到保护。这些风险不同于运行中的主机读取运行中的 guest，但它们都被归在“加密”这个词下。因此，“我们的所有存储都已加密”虽然是真实表述，却回答了另一个问题。

租用机器还存在第二个特有陷阱。加密根文件系统后，每次启动都必须由某个组件提供口令。将口令存放在同一台机器上，例如存放在 keyfile 或未加密的 initramfs 中，主机就可以读取它。将口令输入由供应商控制的控制台，主机同样可以读取它。启动时从其他位置获取口令，只是转移了信任，并没有消除信任，因为提供密钥的服务现在必须确认发起请求的机器确实是你认为的那台机器。最后这个要求正是 attestation 要解决的问题。

AMD SEV-SNP 和 Intel TDX 实际实现了什么

这是两件不同的事。将它们区分开，是理解这一主题的关键：内存加密和远程证明。

先看内存加密。AMD SEV-SNP（Secure Encrypted Virtualization with Secure Nested Paging）为每个来宾分配独立的内存加密密钥。密钥存储在 AMD Secure Processor 中。它是同一芯片上的独立核心，虚拟机管理程序无法看到该密钥。内存控制器只为密钥所属的来宾在写入时加密、读取时解密。主机仍然可以转储这段内存，但得到的内容是密文。

Intel TDX（Trust Domain Extensions）通过另一种方式实现相同的结果。来宾会变成一个信任域，其内存会关联一个私有密钥标识符。所有进出信任域的转换都由 TDX module 监管。TDX module 是一段由 Intel 签名的代码，运行在虚拟机管理程序无法进入的处理器模式中。从租户的角度看，结果相同：虚拟机管理程序可以分配你的内存并调度你的 CPU，但无法读取你的内存。

SEV-SNP 中的 SNP 部分经常被忽略，但它承担了关键作用。加密可以阻止主机读取页面，但不能阻止主机移动页面。能够重新映射来宾物理页面的虚拟机管理程序可以重放旧内容、让两个来宾地址指向同一个页面，或返回一个此前被换出的页面。这些操作都可以在不解密任何内容的情况下构成有效攻击。SNP 添加了 Reverse Map Table。CPU 在访问内存时会查询该结构，以记录每个页面属于哪个来宾。未经来宾请求的重新映射会触发错误，而不会成功执行。TDX 也有对应的机制。没有这一完整性层，你只能防御被动主机，无法防御主动主机。

两者都不会改变这一点：主机仍然可以启动你的 VM、停止它、决定何时为它分配 CPU 核心，也可以直接丢弃它。机密计算可以保护机密性和完整性，但可用性和性能仍完全由主机控制。因此，嘈杂邻居导致的 CPU steal time 不会受到任何影响。

远程证明如何证明仅加密无法证明的事实

仅靠加密仍会留下一个漏洞。您向云服务商申请机密虚拟机，对方提供了一台虚拟机。您如何确认内存加密已启用？您无法通过询问虚拟机来确认，因为虚拟机对整个系统的认知都由 hypervisor 提供，而您要检查的正是 hypervisor。不诚实的主机，或配置错误的主机，可以向您提供一台完全普通的虚拟机；您在其中运行的每条命令，都是由您不信任的那一层返回结果。

远程证明可以闭合这个验证链路。CPU 本身会生成一份带签名的报告。在 SEV-SNP 中，报告由该物理芯片专属的密钥签名，并由 AMD 自己的证书链认证。您从 AMD 获取这条证书链，而不是从云服务商获取。TDX 会生成一份由 Intel 签发的证明密钥支持的 quote。报告包含启动度量值，即虚拟机启动时所用完整内存的哈希，其中包括固件、内核、initrd 和内核命令行。您在机器外部，根据芯片厂商的根证书验证签名，再将该度量值与预期启动内容进行比对。

直接说明它的作用。远程证明让不在这台机器上的一方能够决定是否信任这台机器。它之所以有用，是因为可以根据证明结果释放机密：数据库密码和解密密钥根本不会存放在镜像中，而是由其他位置的服务保存。该服务只有在检查新鲜报告并确认其中包含预期度量值后，才会将这些机密交给虚拟机。如果主机启动了被修改的内核，或在完全未启用 SEV-SNP 的情况下运行虚拟机，度量值就会改变，或者无法生成有效报告，机密也就不会被释放。没有远程证明的加密，只能保护数据免受您已经选择信任的主机攻击。远程证明让您不必再预先选择信任对象。

相关工具是开放的，您可以阅读其代码。snpguest命令行工具会在 AMD guest 内部与 /dev/sev-guest设备通信，请求报告，并根据证书链验证报告。平台细节在这里很重要：在 Azure 机密虚拟机上，该设备通常不会以这种方式暴露给 guest，因此工具需要使用不同的构建版本和不同的标志。远程证明已经可以工作，但目前还不能在所有平台上以完全相同的方式工作。

机密计算无法防护的对象

遭入侵的来宾系统。 SEV-SNP 可保护 VM 免受外部攻击，但无法防护已经进入 VM 的攻击者，因为对 CPU 而言，该攻击者就是你自己。未打补丁的 Web 应用，或逃逸容器并进入你自己的内核，在机密 VM 中同样有效。此时加密反而帮助了入侵者，因为主机也无法检查这部分内存来协助你。RAM 已加密，并不会让遭入侵后恢复 VPS变得更容易。

你自己的应用程序。 防护边界止于 VM 边缘。你的代码写入日志文件，或发送到第三方 API 的数据，已经离开了 TEE（可信执行环境），这是受保护区域的名称。加密内存不会审计你的代码。

被窃取的凭据。 远程证明报告会说明启动了哪些软件，但不会说明之后是谁登录。泄露的 SSH 密钥可以像登录其他 VM 一样快速地打开机密 VM，因此对几乎所有读者来说，强化 VPS 上的 SSH 访问仍然是价值更高的工作。

所有不属于内存的对象。 SEV-SNP 和 TDX 会加密 RAM。除非你自行加密，否则虚拟磁盘、网络流量、快照和备份都不受保护。在超大规模云厂商提供的机密 VM 产品中，OS 磁盘由独立机制处理，并使用单独的密钥管理，正是因为 CPU 功能无法覆盖磁盘。

物理攻击，这是其中最棘手的一项。 一系列已发表的研究表明，内存总线是较薄弱的边界。BadRAM（CVE-2024-21944、2024）篡改内存模块上的 SPD 芯片，使 CPU 将物理地址视为别名，所需零件成本约为十美元。Battering RAM（2025）在 CPU 和 DRAM 之间放置了成本约为五十美元的中间设备，并绕过了为应对前一种攻击而加入的启动时地址别名检查。TEE.fail（2025）将这一思路扩展到 DDR5，并报告称可针对当前服务器硬件上的 Intel 和 AMD 机密计算提取密文。确定性内存加密也会造成问题：相同地址上的相同明文会产生相同的密文，学术研究已将其单独转化为侧信道。上述每种攻击都需要对机器进行物理访问，并获得不受干扰的操作时间。注意，这描述的是谁。机密计算将主机读取内存的方式，从执行一条命令改为使用硬件、物理访问和实际操作。这是实质性且幅度很大的改进，但其安全承诺小于“主机无法读取内存”。

今天可以买到机密 VPS 吗

截至 2026 年 8 月，机密 VM 已成为大型云服务商的产品线。Microsoft Azure 提供 SEV-SNP 规格和 TDX 规格。Google Cloud 提供 Confidential VM。AWS 仅在少数区域的少数实例系列中提供 AmdSevSnp CPU 选项。独立 VPS 主机商很少主动列出此功能。少数主机商会宣传 SEV-SNP，但数量很少，因此最可靠的做法是直接询问，而不是自行假定。

这些原因是由平台结构决定的。了解这些原因后，您就能正确理解主机商的回复。

• 硅片型号有明确要求。SEV-SNP 需要第三代 AMD EPYC 或更高版本，TDX 需要较新的 Intel Xeon Scalable。主机商如果多年来一直按每核心价格采购设备，其服务器群通常是混合配置。因此，该功能可能只存在于部分节点上。
• 主机软件版本较新。Ubuntu 从 24.04 LTS 开始支持 SEV-SNP 客户机，而主机端支持（包括 QEMU 和 OVMF 固件支持）在之后的 25.04 才加入。这比稳定托管平台通常运行的软件栈更新。
• 实时迁移更复杂。将运行中的客户机迁移到其他主机时，需要复制其内存，而主机无法读取这些内存。主机商依靠实时迁移在维护前疏散节点，因此失去实时迁移会改变整个托管平台的运维方式。
• 部署密度会降低。单台主机可同时运行的机密客户机数量受硬件限制，远低于大型节点可运行的普通客户机数量。低价 VPS 依赖这种部署密度。
• 远程证明会带来持续的支持负担。除非租户能够获取证书链并知道应验证哪个度量值，否则报告没有实际意义。因此，主机商必须发布并维护相关信息，而这些信息会随着每次固件更新而变化。

这些都不是对任何主机商的批评。它们只是说明了该功能为何处于目前的状态。

如何询问主机是否支持 SEV-SNP 或 TDX

支持团队会回答您提出的问题。问题含糊，得到的答复也会让人安心，但没有实际意义。询问数据是否加密时，您会听到“所有存储都已静态加密”。这句话虽然属实，但说的是磁盘。请改为询问更具体的问题。以下 5 个问题值得直接照发。

1. 您是否提供为 guest 启用 AMD SEV-SNP 或 Intel TDX 的实例？哪些套餐支持？
2. 这是在创建实例时按实例选择的功能，还是主机的固有属性、无法由我选择？
3. 在 guest 内部，我能否获取硬件证明报告？报告中是否存在 /dev/sev-guest？
4. 您是否提供或透传用于根据 CPU 厂商验证该报告的证书链？
5. 支持哪些区域和主机代际？这是否会限制调整实例规格或迁移？

请按以下方式理解回复。问题 1 的答案为“是”，但问题 3 和 4 的答案为“否”，表示您获得了无法验证的内存加密。它可以抵御转售的内存模块，但对主机本身的防护价值很小。因为您仍在相信运营商对某项功能的描述，而这项功能的目的正是消除对运营商的信任需求。只谈合规或泛泛而谈加密的答复，都应视为“否”。问题 5 没有得到答复，通常意味着该功能只适用于一个区域中的一个实例系列。

关于价格和实例选择，不要期待简单加价后即可使用，而应预期可选范围更窄。机密计算实例通常属于独立系列，规格和区域更少。实际成本往往不是小时费率，而是这些限制。请按您实际要运行的具体规格进行报价。

如何检查已有的 VPS

这些命令在客户机内部运行，耗时不到 1 分钟。请将输出视为重要线索，而不是确凿证据，因为客户机看到的所有信息都由虚拟机监控程序提供。

systemd-detect-virt
systemd-detect-virt --cvm

第一条命令会显示内核检测到的虚拟化技术。第二条命令会报告机密虚拟机技术，可能的值包括 sev、sev-es、sev-snp 和 tdx。--cvm 是较新的选项，因此如果系统无法识别它，请先运行 systemctl --version。

sudo dmesg | grep -i -E 'sev|tdx|memory encryption'
sudo journalctl -k | grep -i -E 'sev|tdx|memory encryption'

启用 AMD 内存加密的客户机会输出一行以 Memory Encryption Features active: 开头的启动信息，其后列出正在使用的技术。信任域会在早期启动阶段输出专属的 TDX 信息。还应运行 journalctl 形式的命令，因为对于已长时间运行的服务器，dmesg 环形缓冲区可能已经循环覆盖，导致启动信息被丢弃。

grep -m1 ^flags /proc/cpuinfo | tr ' ' '\n' | grep -i -E 'sev|tdx'
ls -l /dev/sev-guest /dev/tdx-guest

请谨慎解读 CPU 标志。/proc/cpuinfo 显示虚拟机监控程序选择呈现给客户机的 CPU 型号，因此出现 sev 标志，可能只表示物理 CPU 支持该功能，而您的虚拟机并未使用它。tdx_guest 是更直接的信号，因为该标志描述的是客户机本身。证明工具需要使用设备文件：AMD 使用 /dev/sev-guest，Intel 使用 TDX 客户机设备；如果不存在相应文件，ls 会明确报告这一点。在某些平台上，即使虚拟机属于机密虚拟机，设备也会被有意隐藏，导致客户机无法看到。因此，这项检查只能用于确认，不能用于排除。

如果这些命令都没有发现任何信息，则您的服务器不支持该功能。这是普通 VPS 托管中的预期结果，并不表示系统出现故障。

答案为“否”时怎么办

答案确实会是“否”。有用的做法不是放弃这个问题，而是降低它带来的代价。几项习惯就能解决大部分问题，而且都不需要特殊硬件。

在本机加密离开本机的数据。 备份最重要。restic 和 age 等工具会在客户端加密数据，然后才将其发送到目标位置，因此存储提供商只会保存密文，不会接触密钥。您自己的服务器之间也应使用 TLS（传输层安全）保护流量，包括跨越提供商的私有网络时，因为私有网络仍然是您无法管理的网络。

不要将密钥放入镜像或 git。 写入 VM 镜像或提交到代码仓库的密钥，对所有能读取镜像或仓库的人都已暴露，而这类人的范围通常远大于负责运行 hypervisor 的人员。请将密钥存放在加密存储中，并在部署时解密。使用 Ansible Vault 加密密钥 是配置开销较低的做法，对于大多数小型服务器集群已经足够。

限制每台服务器可访问的资源。 这是最能改变结果的习惯。请设想攻击者读取了这台机器的全部内存后，能够取得什么。如果其中包括一把可以解密十年客户记录的密钥，那么 hypervisor 只是较小的问题：这把密钥正放在面向公网的 Web 服务器上。为每台服务器配置仅能完成其工作所需的最小权限凭据，并设置较短的有效期和经过演练的轮换流程。这样，攻击者读取某台主机内存时，您承担的损失就不会超过该主机原本能够造成的损失。

不要将无法轮换的密钥放在 VPS 上。 密钥轮换是能够在实际环境中持续生效的控制措施。本页的其他内容都假设您最终会发现问题。无法发现问题时，您需要执行的就是密钥轮换。

修复真正正在攻击您的问题。 对几乎所有读者而言，导致服务器遭到入侵的现实路径是未打补丁的服务或被盗凭据，而不是数据中心的工程师读取 RAM。检查服务器是否存在已知 CVE 和 Ubuntu Pro 如何扩大服务器的补丁覆盖范围 对降低风险的作用，超过任何 CPU 特性。在新机器上执行 新 VPS 上线后的前十分钟，是您能完成的成本最低的安全工作。

如果确实有一个工作负载需要硬件信任边界，请将其作为独立工作负载处理。将这一部分运行在提供此类服务的提供商的机密 VM 上，或运行在您控制的硬件上，其余部分仍放在成本可接受的位置。按敏感性拆分系统是常见的架构方式，而且今天就可以实现；机密 VPS 则还无法做到这一点。

FAQ

我的 VPS 提供商能读取服务器内存吗？

在普通 VPS 托管中，可以。虚拟机监控程序负责分配和映射来宾系统的 RAM，因此主机上的 root 用户可以读取这些内存，例如通过 /proc/<pid>/mem 中的 QEMU 进程读取，或将来宾系统的内存转储到文件中。来宾系统内部无法阻止或检测此操作。AMD SEV-SNP 和 Intel TDX 可用于消除这种能力，但大多数 VPS 套餐并不提供这些功能。在普通 VPS 上，限制提供商访问权限的主要是提供商自身的控制措施和员工政策，而不是技术本身。

全磁盘加密能保护 VPS 数据不被托管提供商读取吗？

服务器运行时不能。文件系统要保持可读，卷密钥就必须留在内核内存中，因此密钥和经过解密处理的数据都会存在于主机可以读取的内存中。磁盘加密可以保护静态数据，例如故障后返还给供应商的磁盘，或已分离但被遗忘的备份卷。这些风险值得防护，但它们不同于运行中的主机读取运行中的来宾系统这一风险。

如何检查 VPS 是否使用 AMD SEV-SNP 或 Intel TDX？

在来宾系统中运行 systemd-detect-virt --cvm，然后运行 sudo dmesg | grep -i -E 'sev|tdx' 和 ls -l /dev/sev-guest。启用了 AMD 内存加密的来宾系统会输出以 Memory Encryption Features active: 开头的启动行；Intel 信任域会在 /proc/cpuinfo 中包含 tdx_guest 标志。所有这些结果都由虚拟机监控程序传递给你，因此只能作为参考。唯一的证明是经过签名的证明报告，并且你需要在机器外部根据 CPU 厂商的证书链验证该报告。

证明在内存加密之上增加了什么？

它证明加密确实处于启用状态，并且机器启动了你预期的软件。无法验证的内存加密，仍然要求你相信运营方的说法。证明报告由 CPU 签名，包含虚拟机初始内存的度量值，其中涵盖固件、内核、initrd 和内核命令行；同时，报告会在机器外部根据芯片厂商的根证书进行验证。这样才能实现值得采用的模式：只有在报告验证通过后，才将其他位置保存的机密信息释放给虚拟机。

为机密计算支付额外费用值得吗？

这取决于基础设施运营方是否属于你的威胁模型。对于受监管数据，或用于保护他人数据的密钥，这是唯一可用的技术方案；与其他选择相比，超大规模云厂商的机密计算实例价格并不高。对于个人网站或小型服务，将同样的资金用于打补丁和凭据管理，通常能获得更高的安全性。在购买具备这些硬件功能的设备前，应先如实判断你运行的是什么。