资讯动态

Cloud Hypervisor 运行 Intel TDX 机密虚拟机完整指南:TDVF 与 TDShim 双路径实战

发布时间:2026/9/17 18:38:16 来源:尧图企业网站定制
Cloud Hypervisor 运行 Intel TDX 机密虚拟机完整指南TDVF 与 TDShim 双路径实战【免费下载链接】cloud-hypervisorA Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.项目地址: https://gitcode.com/GitHub_Trending/cl/cloud-hypervisor导读本文以 Cloud Hypervisor 仓库的 docs/intel_tdx.md 文档为核心骨架系统讲解如何在 Cloud Hypervisor 上运行 Intel® TDXTrust Domain Extensions机密虚拟机。你将掌握 TDX 的软硬件前置条件、TDVF 与 TDShim 两种固件的构建方法、两种对应的启动命令含调试变体、--platform tdxon参数的正确用法以及当前 TDX 客户机内核已知的功能限制并理解 Cloud Hypervisor 源码中 TDX 初始化的底层调用链。一、Intel TDX 是什么Intel® Trust Domain ExtensionsIntel® TDX是英特尔推出的一项硬件辅助机密计算技术其核心设计目标是将虚拟机Trust DomainTD与 VMM、宿主机 hypervisor 以及宿主机平台上的其他软件彻底隔离。即使宿主机内核或 VMM 被攻破也无法读取 TD 内部的内存内容或篡改其运行状态。TDX 的完整技术栈分为三个层面TDX 硬件需要支持 TDX 的英特尔 CPU 平台并在 BIOS 中启用宿主机侧需要 Linux 内核的 TDX 支持KVM 侧改动官方维护在 Intel 的 KVM TDX tree 中客户机侧需要TDX enlightenedTDX 感知的客户机内核与配套固件TDVF 或 TDShim。在 Cloud Hypervisor 中运行 TDX 虚拟机时VMM 本身运行在宿主机侧只负责加载固件、初始化 TD 环境并代理 TD 的退出事件而 TD 内部的内存加密、寄存器保护等都由硬件与固件协同完成。二、运行环境前置条件运行 TDX VM 需要同时满足以下条件硬件一台在硬件层面启用 TDX 的机器需要在 BIOS 中开启相关选项宿主机内核宿主机操作系统必须使用 KVM TDX tree 编译的内核该内核包含了 TDX 所需的 KVM 侧补丁测试环境准备也可以直接使用 TDX Linux 提供的工具和脚本快速搭建 TDX 测试环境这些脚本可完成宿主机软件包安装、客户机镜像制作以及 TDX host/guest 定制内核的编译客户机镜像必须是定制镜像其中包含由 Guest TDX tree 编译的 TDX 客户机内核。从 Cloud Hypervisor 源码看TDX 是一个编译期特性而不是默认启用vmm/src/vm.rs、vmm/src/config.rs中所有 TDX 相关代码均以#[cfg(feature tdx)]条件编译。因此在准备运行环境时还需要使用开启了tdxfeature 的 Cloud Hypervisor 二进制。Cloud Hypervisor 支持两种 TDX 固件加载方式对应两条完全不同的启动路径启动方式固件加载方式适用场景TDVFEDK2 项目 编译的OVMF.fd固件启动固件内部再加载客户机内核传统固件引导场景TDShimConfidential Containers 项目 编译的final.bin直接内核启动direct kernel boot配合--kernel与--cmdline容器等轻量场景三、方式一使用 TDVF 固件启动3.1 构建 TDVF 固件TDVF 是 EDK2 项目为 TDX 定制的 OVMF 变体构建步骤如下sudo apt-get update sudo apt-get install uuid-dev nasm iasl build-essential python3-distutils git git clone https://github.com/tianocore/edk2.git cd edk2 git checkout 13b97736c876919b9786055829caaa4fa46984b7 source ./edksetup.sh git submodule update --init --recursive make -C BaseTools -j nproc build -p OvmfPkg/IntelTdx/IntelTdxX64.dsc -a X64 -t GCC5 -b RELEASE注意Cloud Hypervisor 官方当前测试验证的 TDVF 版本为 commit13b97736c876919b9786055829caaa4fa46984b7建议 checkout 到该提交以保证兼容性。构建产物位于edk2/Build/IntelTdx/RELEASE_GCC5/FV/OVMF.fd。如果需要固件的调试日志改用以下命令启用串口调试输出build -p OvmfPkg/IntelTdx/IntelTdxX64.dsc -a X64 -t GCC5 -D DEBUG_ON_SERIAL_PORTTRUE该命令的构建产物位于edk2/Build/IntelTdx/DEBUG_GCC5/FV/OVMF.fd。3.2 编译带 tdx 特性的 Cloud HypervisorTDX 支持属于编译期可选特性构建命令cargo build --features tdx在 vmm/src/config.rs 中可以看到--platform参数的可选语法只有在编译期启用tdxfeature 时才会追加tdxon|off否则该参数根本不存在。同理TDVF 解析与 TDX 内存初始化等代码也全部被#[cfg(feature tdx)]包裹。3.3 启动 TDX VM提供前面编译好的固件加上包含 TDX enlightened 内核的客户机镜像即可启动./cloud-hypervisor \ --platform tdxon \ --firmware edk2/Build/IntelTdx/RELEASE_GCC5/FV/OVMF.fd \ --cpus boot1 \ --memory size1G \ --disk pathtdx_guest_img,image_typeraw官方测试镜像td-guest-rhel8.5.raw的内核启动参数中已包含consolehvc0即客户机内核日志会输出到virtio-console设备上。3.4 带固件调试日志的变体./cloud-hypervisor \ --platform tdxon \ --firmware edk2/Build/IntelTdx/DEBUG_GCC5/FV/OVMF.fd \ --cpus boot1 \ --memory size1G \ --disk pathtdx_guest_img,image_typeraw \ --serial file/tmp/ch_serial \ --console tty这里通过--serial file/tmp/ch_serial将串口重定向到文件、--console tty将控制台绑定到当前终端从而捕获固件与内核的调试输出。四、方式二使用 TDShim 直接启动内核4.1 TDShim 简介TDShim 是 TDVF 的轻量级替代品由 Rust 编写专为**直接内核启动direct kernel boot**设计特别适合容器类用例。Cloud Hypervisor 官方当前验证的版本为v0.8.0。4.2 构建 TDShim构建前需要先安装Rust、NASM和LLVMgit clone https://github.com/confidential-containers/td-shim cd td-shim git checkout v0.8.0 cargo install cargo-xbuild export CCclang export ARllvm-ar export CC_x86_64_unknown_noneclang export AR_x86_64_unknown_nonellvm-ar git submodule update --init --recursive ./sh_script/preparation.sh cargo image --release这里的关键点在于由于 TDShim 需要为x86_64-unknown-none目标交叉编译必须显式指定clang作为 C 编译器、llvm-ar作为归档工具包括对应的交叉编译环境变量。Release 构建产物为td-shim/target/release/final.bin。如果需要 TDShim 的调试日志改用cargo imageDebug 构建产物为td-shim/target/debug/final.bin。4.3 启动 TDX VM直接内核启动TDShim 路径下需要同时提供内核镜像和内核启动参数--kernel--cmdline内核必须来自 Guest TDX tree 或通过 TDX Linux 构建./cloud-hypervisor \ --platform tdxon \ --firmware td-shim/target/release/final.bin \ --kernel bzImage \ --cmdline root/dev/vda3 consolehvc0 rw \ --cpus boot1 \ --memory size1G \ --disk pathtdx_guest_img,image_typeraw4.4 带 TDShim 调试日志的变体./cloud-hypervisor \ --platform tdxon \ --firmware td-shim/target/debug/final.bin \ --kernel bzImage \ --cmdline root/dev/vda3 consolehvc0 rw \ --cpus boot1 \ --memory size1G \ --disk pathtdx_guest_img,image_typeraw五、--platform tdxon参数解析与配置校验--platform是一个逗号分隔的键值对参数。在编译期启用tdxfeature 时其完整语法会追加tdxon|off见 vmm/src/config.rs默认值为off对应源码中unwrap_or(Toggle(false))见 vmm/src/config.rs。启动时 Cloud Hypervisor 会对 TDX 配置做两项硬性校验见 vmm/src/config.rs必须提供固件tdxon时若--firmware未设置直接报错TdxFirmwareMissing。无论走 TDVF 还是 TDShim 路径TDX 启动都必须有固件参与不支持 CPU 热插拔tdxon时max_vcpus必须等于boot_vcpus否则报错TdxNoCpuHotplug。也就是说启动时指定的 CPU 数量必须是最终数量不能预留可热插拔的 vCPU。此外从 vmm/src/vm.rs 和 vmm/src/cpu.rs 的源码可以推断TDX 模式下内存映射与设备初始化均采用**静态非动态**方式因为机密虚拟机不允许在运行时动态变更内存布局或热插拔设备。六、Cloud Hypervisor 的 TDX 初始化调用链源码级从 vmm/src/vm.rs 的init_tdx_if_enabled()可以看出启动流程的关键一步当配置检测到tdxon后会调用vm.tdx_init(cpuid, max_vcpus)完成 TD 的初始化随后在创建 vCPU 时传递 TDX 状态、并在 vCPU 退出时通过get_tdx_exit_details()处理 TDX 特定的退出事件见 vmm/src/cpu.rs。TDX 固件加载的核心实现在arch/src/x86_64/tdx/mod.rsTDVF 描述符解析Cloud Hypervisor 通过parse_tdvf_sections()解析固件中的 TDVF 描述符。解析时会先尝试在固件文件末尾通过 GUID 表定位描述符偏移GUID96b582de-1fb2-45f7-baea-a366c55a082d为表尾、e47a6535-984a-4798-865e-4685a7bf8ec2为元数据偏移如果找不到则回退到旧式方法——从文件末尾偏移 0x20 处读取 32 位描述符偏移对应源码tdvf_descriptor_offset()中的注释 TDVF Metadata Pointer描述符校验描述符必须以TDVF签名开头版本必须为 1长度必须与节表大小严格一致InvalidDescriptorSignature/InvalidDescriptorVersion/InvalidDescriptorSize三种错误分别对应这些校验失败节类型描述符内包含BfvBoot Firmware Volume、CfvConfig Firmware Volume、TdHob、TempMem、PermMem、Payload、PayloadParam等节类型Cloud Hypervisor 依据这些节将固件数据放置到客户机内存的正确位置HOB 构建随后 Cloud Hypervisor 会构建 TD HOBHand-Off Block列表——包括HandoffInfoTable、ResourceDescriptor、GuidExtension等结构——写入客户机内存并通过vm.tdx_init(hob_address)把 HOB 地址传给 TDX见 vmm/src/cpu.rs内存初始化与收尾在 vmm/src/vm.rs 的init_tdx_memory()中通过vm.tdx_init_memory_region()将各固件节所在的内存区域标记为 TD 内存最后调用vm.tdx_finalize()结束 TD 初始化。这些调用最终都经过 hypervisor/src/hypervisor.rs 定义的 Vm trait 抽象在 hypervisor/src/kvm/x86_64/mod.rs 中落地为对应的 KVM ioctl。另外TDX 模式下 ACPI 表的生成走专用路径create_acpi_tables_tdx()见 vmm/src/acpi.rs与普通虚拟机使用的表集合有所差异。七、TDX 客户机内核的已知限制7.1 串口被禁用官方最新测试镜像td-guest-rhel8.5.raw中的客户机内核已禁用串口支持。这意味着即使你在内核启动参数里加上consolettyS0也不会生效客户机不会通过传统串口输出任何日志。这也是文档中两条启动命令都依赖consolehvc0virtio-console的原因——串口不可用时virtio 控制台是获取客户机日志的主要通道。7.2 PCI 热插拔ACPI 方式不可用除非客户机内核带tdx_disable_filter参数启动否则 TDX 环境下 ACPI 中负责 PCI 热插拔的设备PCI hotplug controller、PCI Express Bus 以及 Generic Event Device不会被允许出现对应驱动无法加载因此PCI 热插拔功能不可用。结合第五节提到的TDX 模式不支持 CPU 热插拔校验可以推断TDX 客户机在资源弹性上受限较多CPU 与 PCI 设备的热插拔在当前的 TDX 内核下均不受支持规划 TDX 工作负载时需要一次性配置好所需的资源。八、排障与调试速查现象可能原因排查/解决方式启动报TdxFirmwareMissing--platform tdxon但未指定--firmware必须同时提供 TDVF 或 TDShim 固件启动报TdxNoCpuHotplug--cpus bootN,maxM中 M 大于 N让max等于boot固件阶段无日志使用了 RELEASE 构建使用-D DEBUG_ON_SERIAL_PORTTRUE构建 DEBUG 固件并配合--serial file... --console tty启动客户机无内核日志内核串口被禁用确认内核启动参数使用consolehvc0virtio-console--platform tdx...报参数不存在二进制未开启 tdx feature使用cargo build --features tdx重新构建九、总结在 Cloud Hypervisor 上运行 TDX 机密虚拟机的完整路径是准备 TDX 硬件与宿主机内核KVM TDX tree→ 编译 TDVF 或 TDShim 固件 →cargo build --features tdx构建带 TDX 支持的 Cloud Hypervisor → 使用--platform tdxon配合固件与定制镜像启动。TDVF 路径适合传统固件引导TDShim 路径适合容器的直接内核启动。启动时注意 CPU 数量不可热插拔、必须携带固件两项硬性约束调试阶段善用 DEBUG 固件构建与--serial/--console参数并牢记当前 TDX 客户机内核的串口与 PCI 热插拔限制。【免费下载链接】cloud-hypervisorA Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.项目地址: https://gitcode.com/GitHub_Trending/cl/cloud-hypervisor创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价