arch/x86/tdx.rst

1 .. SPDX-License-Identifier: GPL-2.0
18 CPU-attested software module called 'the TDX module' runs inside the new
22 TDX also leverages Intel Multi-Key Total Memory Encryption (MKTME) to
23 provide crypto-protection to the VMs.  TDX reserves part of MKTME KeyIDs
32 TDX boot-time detection
33 -----------------------
36 boot.  Below dmesg shows when TDX is enabled by BIOS::
41 ---------------------------------------
59 Besides initializing the TDX module, a per-cpu initialization SEAMCALL
103 ------------------------------------------
110 of memory regions (out of CMRs) as "TDX-usable" memory and pass those
111 regions to the TDX module.  Once this is done, those "TDX-usable" memory
115 in the page allocator are TDX memory.  Specifically, the kernel uses all
116 system memory in the core-mm "at the time of TDX module initialization"
117 as TDX memory, and in the meantime, refuses to online any non-TDX-memory
124 machine's runtime.  A non-buggy BIOS should never support hot-removal of
131 TDX module requires the per-cpu initialization SEAMCALL must be done on
136 TDX doesn't support physical (ACPI) CPU hotplug.  During machine boot,
137 TDX verifies all boot-time present logical CPUs are TDX compatible before
138 enabling TDX.  A non-buggy BIOS should never support hot-add/removal of
162 non-temporal write instructions (like MOVNTI), or through UC/WC memory
168 software-triggered issue.  But in the end, this issue is hard to trigger.
181 The kernel uses S3 for suspend-to-ram, and use S4 and deeper states for
185 The kernel disables TDX during early boot when hibernation support is
193 ACPI S3 is disabled during kernel early boot if TDX is enabled.  The user
204 TDX includes new hypercall-like mechanisms for communicating from the
208 ------------------
210 TDX guests behave differently from bare-metal and traditional VMX guests.
217 Instruction-based #VE
220 - Port I/O (INS, OUTS, IN, OUT)
221 - HLT
222 - MONITOR, MWAIT
223 - WBINVD, INVD
224 - VMCALL
225 - RDMSR*,WRMSR*
226 - CPUID*
228 Instruction-based #GP
231 - All VMX instructions: INVEPT, INVVPID, VMCLEAR, VMFUNC, VMLAUNCH,
233 - ENCLS, ENCLU
234 - GETSEC
235 - RSM
236 - ENQCMD
237 - RDMSR*,WRMSR*
244 - #GP generated
245 - #VE generated
246 - "Just works"
263 For some CPUID leaves and sub-leaves, the virtualized bit fields of CPUID
268 - Bit fields for which the hypervisor controls the value seen by the guest
271 - Bit fields for which the hypervisor configures the value such that the
276 A #VE is generated for CPUID leaves and sub-leaves that the TDX module does
281 ----------------------
290 private or shared.  It selects the behavior with a bit in its page table
306 stacks.  A good rule of thumb is that hypervisor-shared memory should be
323 A modest amount of memory (typically 512M) is pre-accepted by the firmware
328 "blocked" state. However, if it does this, page access will not generate a
333 -----------------
335 Just like page faults or #GP's, #VE exceptions can be either handled or be
350 #VE-triggering actions (discussed above) while this block is in place.
355 -------------
357 In non-TDX VMs, MMIO is usually implemented by giving a guest access to a
377 -------------------------
379 All TDX guest memory starts out as private at boot.  This memory can not
393 converted to shared on boot.
408 the guest boot process using the build time measurement register (MRTD)
422 from the TDX module. TDREPORT is a fixed-size data structure generated by
423 the TDX module which contains guest-specific information (such as build
424 and boot measurements), platform security version, and the MAC to protect
425 the integrity of the TDREPORT. A user-provided 64-Byte REPORTDATA is used
431 After getting the TDREPORT, the second step of the attestation process
446 https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.…