| 1 | Intel Trusted Domain eXtension (TDX) |
| 2 | ==================================== |
| 3 | |
| 4 | Intel Trusted Domain eXtensions (TDX) refers to an Intel technology that extends |
| 5 | Virtual Machine Extensions (VMX) and Multi-Key Total Memory Encryption (MKTME) |
| 6 | with a new kind of virtual machine guest called a Trust Domain (TD). A TD runs |
| 7 | in a CPU mode that is designed to protect the confidentiality of its memory |
| 8 | contents and its CPU state from any other software, including the hosting |
| 9 | Virtual Machine Monitor (VMM), unless explicitly shared by the TD itself. |
| 10 | |
| 11 | Prerequisites |
| 12 | ------------- |
| 13 | |
| 14 | To run TD, the physical machine needs to have TDX module loaded and initialized |
| 15 | while KVM hypervisor has TDX support and has TDX enabled. If those requirements |
| 16 | are met, the ``KVM_CAP_VM_TYPES`` will report the support of ``KVM_X86_TDX_VM``. |
| 17 | |
| 18 | Trust Domain Virtual Firmware (TDVF) |
| 19 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 20 | |
| 21 | Trust Domain Virtual Firmware (TDVF) is required to provide TD services to boot |
| 22 | TD Guest OS. TDVF needs to be copied to guest private memory and measured before |
| 23 | the TD boots. |
| 24 | |
| 25 | KVM vcpu ioctl ``KVM_TDX_INIT_MEM_REGION`` can be used to populate the TDVF |
| 26 | content into its private memory. |
| 27 | |
| 28 | Since TDX doesn't support readonly memslot, TDVF cannot be mapped as pflash |
| 29 | device and it actually works as RAM. "-bios" option is chosen to load TDVF. |
| 30 | |
| 31 | OVMF is the opensource firmware that implements the TDVF support. Thus the |
| 32 | command line to specify and load TDVF is ``-bios OVMF.fd`` |
| 33 | |
| 34 | Feature Configuration |
| 35 | --------------------- |
| 36 | |
| 37 | Unlike non-TDX VM, the CPU features (enumerated by CPU or MSR) of a TD are not |
| 38 | under full control of VMM. VMM can only configure part of features of a TD on |
| 39 | ``KVM_TDX_INIT_VM`` command of VM scope ``MEMORY_ENCRYPT_OP`` ioctl. |
| 40 | |
| 41 | The configurable features have three types: |
| 42 | |
| 43 | - Attributes: |
| 44 | - PKS (bit 30) controls whether Supervisor Protection Keys is exposed to TD, |
| 45 | which determines related CPUID bit and CR4 bit; |
| 46 | - PERFMON (bit 63) controls whether PMU is exposed to TD. |
| 47 | |
| 48 | - XSAVE related features (XFAM): |
| 49 | XFAM is a 64b mask, which has the same format as XCR0 or IA32_XSS MSR. It |
| 50 | determines the set of extended features available for use by the guest TD. |
| 51 | |
| 52 | - CPUID features: |
| 53 | Only some bits of some CPUID leaves are directly configurable by VMM. |
| 54 | |
| 55 | What features can be configured is reported via TDX capabilities. |
| 56 | |
| 57 | TDX capabilities |
| 58 | ~~~~~~~~~~~~~~~~ |
| 59 | |
| 60 | The VM scope ``MEMORY_ENCRYPT_OP`` ioctl provides command ``KVM_TDX_CAPABILITIES`` |
| 61 | to get the TDX capabilities from KVM. It returns a data structure of |
| 62 | ``struct kvm_tdx_capabilities``, which tells the supported configuration of |
| 63 | attributes, XFAM and CPUIDs. |
| 64 | |
| 65 | TD attributes |
| 66 | ~~~~~~~~~~~~~ |
| 67 | |
| 68 | QEMU supports configuring raw 64-bit TD attributes directly via "attributes" |
| 69 | property of "tdx-guest" object. Note, it's users' responsibility to provide a |
| 70 | valid value because some bits may not supported by current QEMU or KVM yet. |
| 71 | |
| 72 | QEMU also supports the configuration of individual attribute bits that are |
| 73 | supported by it, via properties of "tdx-guest" object. |
| 74 | E.g., "sept-ve-disable" (bit 28). |
| 75 | |
| 76 | MSR based features |
| 77 | ~~~~~~~~~~~~~~~~~~ |
| 78 | |
| 79 | Current KVM doesn't support MSR based feature (e.g., MSR_IA32_ARCH_CAPABILITIES) |
| 80 | configuration for TDX, and it's a future work to enable it in QEMU when KVM adds |
| 81 | support of it. |
| 82 | |
| 83 | Feature check |
| 84 | ~~~~~~~~~~~~~ |
| 85 | |
| 86 | QEMU checks if the final (CPU) features, determined by given cpu model and |
| 87 | explicit feature adjustment of "+featureA/-featureB", can be supported or not. |
| 88 | It can produce feature not supported warning like |
| 89 | |
| 90 | "warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]" |
| 91 | |
| 92 | It can also produce warning like |
| 93 | |
| 94 | "warning: TDX forcibly sets the feature: CPUID.80000007H:EDX.invtsc [bit 8]" |
| 95 | |
| 96 | if the fixed-1 feature is requested to be disabled explicitly. This is newly |
| 97 | added to QEMU for TDX because TDX has fixed-1 features that are forcibly enabled |
| 98 | by TDX module and VMM cannot disable them. |
| 99 | |
| 100 | Launching a TD (TDX VM) |
| 101 | ----------------------- |
| 102 | |
| 103 | To launch a TD, the necessary command line options are tdx-guest object and |
| 104 | split kernel-irqchip, as below: |
| 105 | |
| 106 | .. parsed-literal:: |
| 107 | |
| 108 | |qemu_system_x86| \\ |
| 109 | -accel kvm \\ |
| 110 | -cpu host \\ |
| 111 | -object tdx-guest,id=tdx0 \\ |
| 112 | -machine ...,confidential-guest-support=tdx0 \\ |
| 113 | -bios OVMF.fd \\ |
| 114 | |
| 115 | Restrictions |
| 116 | ------------ |
| 117 | |
| 118 | - kernel-irqchip must be split; |
| 119 | |
| 120 | This is set by default for TDX guest if kernel-irqchip is left on its default |
| 121 | 'auto' setting. |
| 122 | |
| 123 | - No readonly support for private memory; |
| 124 | |
| 125 | - No SMM support: SMM support requires manipulating the guest register states |
| 126 | which is not allowed; |
| 127 | |
| 128 | Debugging |
| 129 | --------- |
| 130 | |
| 131 | Bit 0 of TD attributes, is DEBUG bit, which decides if the TD runs in off-TD |
| 132 | debug mode. When in off-TD debug mode, TD's VCPU state and private memory are |
| 133 | accessible via given SEAMCALLs. This requires KVM to expose APIs to invoke those |
| 134 | SEAMCALLs and corresonponding QEMU change. |
| 135 | |
| 136 | It's targeted as future work. |
| 137 | |
| 138 | TD attestation |
| 139 | -------------- |
| 140 | |
| 141 | In TD guest, the attestation process is used to verify the TDX guest |
| 142 | trustworthiness to other entities before provisioning secrets to the guest. |
| 143 | |
| 144 | TD attestation is initiated first by calling TDG.MR.REPORT inside TD to get the |
| 145 | REPORT. Then the REPORT data needs to be converted into a remotely verifiable |
| 146 | Quote by SGX Quoting Enclave (QE). |
| 147 | |
| 148 | It's a future work in QEMU to add support of TD attestation since it lacks |
| 149 | support in current KVM. |
| 150 | |
| 151 | Live Migration |
| 152 | -------------- |
| 153 | |
| 154 | Future work. |
| 155 | |
| 156 | References |
| 157 | ---------- |
| 158 | |
| 159 | - `TDX Homepage <https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html>`__ |
| 160 | |
| 161 | - `SGX QE <https://github.com/intel/SGXDataCenterAttestationPrimitives/tree/master/QuoteGeneration>`__ |