Attestation Report

Enabling remote attestation for a Trusted Domain (TD) involves several steps. Firstly, measurements of the loaded software are taken during both the build-time and runtime of the TD. Subsequently, the TD's measurements and platform Trusted Computing Base (TCB) information are retrieved, generating a TD report. Finally, a quote is derived from the TD report, which can be used by a third party to verify the authenticity of the TD and ensure it operates on a legitimate TDX platform with the expected TCB versions and software measurements.

Taking Measurements

Taking measurements in TDX involves using two types of measurement registers for each Trusted Domain (TD): The Measurement of the Trust Domain (MRTD) for build-time measurements and four Runtime Measurement Registers (RTMRs) for runtime measurements. These registers can be likened to the TPM's PCRs (Platform Configuration Registers).

The MRTD captures measurements during the TD build process. When the hypervisor adds initial memory pages to the TD during its creation, the MRTD in the TDCS (Trust Domain Control Structure) is extended with measurements of these pages. To initiate measurement, the hypervisor uses the SEAMCALL[TDH.MEM.PAGE.ADD] instruction, calculating a SHA384 update over the ASCII string "MEM.PAGE.ADD" and the Guest Physical Address (GPA) of the page. The resulting hash value extends the MRTD. After copying the page into TD's memory (i.e., mapped and available in the SEPT - Secure Enclave Page Table), the hypervisor calls SEAMCALL[TDH.MR.EXTEND] multiple times to measure the page's content in 256 B blocks. For each block, another SHA384 update is calculated over the ASCII string "MR.EXTEND" and the GPA of the block. A second SHA384 update is also performed over the block's content. Both hash values contribute to extending the MRTD. These initial pages typically contain TD's virtual firmware. The MRTD's measurement excludes pages containing control structures (TDR, TDCS, and TDVPS) and the SEPT. Once the initial set of pages is added, the hypervisor finalizes the MRTD measurement using SEAMCALL[TDH.MR.FINALIZE], preventing further extensions to the MRTD. For example, when initializing a TD using KVM as a Linux hypervisor, the TDVF (virtual firmware of a TD) code is measured into the MRTD.

The RTMRs are general measurement registers labelled 0 through 3, serving TD's runtime measurements. A TD can employ these registers to achieve a measured boot, measuring all software loaded after booting. The RTMRs start initialized to zero. To extend the content of an RTMR, the TD calls TDCALL[TDG.MR.RTMR.EXTEND] with the index of the measurement register and a 64 B-aligned physical address of the 48 B extension buffer containing the value. This call calculates a SHA384 hash over the current value of the specified index measurement register concatenated with the value in the extension buffer: RTMR[index] = SHA384(RTMR[index] || value). For instance, TDVF measures the static/dynamic configuration data into RTMR[0] and the OS kernel, boot parameters, and initrd into RTMR[1].

Generating a TD Report

Inside a Trusted Domain (TD), a TD report is generated using the TDX Module's report function, invoked by the TD calling TDCALL[TDG.MR.REPORT]. This call takes a newly initialized report structure and user report data named REPORTDATA, which is 64 B in size and serves as a nonce to ensure the TD report's freshness. To fulfil the request, the TDX Module utilizes the newly introduced SEAMOPS[SEAMREPORT] instruction, incorporating TD's measurements and REPORTDATA. The CPU then appends Trusted Computing Base (TCB) information related to the SEAM and generates the TD report, protected with integrity, using an HMAC key exclusively accessible to the CPU. Subsequently, the TDX Module returns this TD report to the TD. However, I want to point out that the TD report's verification can only be done on the same platform using the EVERIFYREPORT2 instruction and cannot be performed off the platform.

The figure below illustrates the TD report's structure, comprising three components: REPORTMACSTRUCT, TEE_TCB_INFO, and TD_INFO. The REPORTMACSTRUCT contains header information specifying the structure type as TDX and includes fields for the CPU's Security Version Number (SVN) and hashes of the TEE_TCB_INFO and TD_INFO components. Additionally, it incorporates the REPORTDATA provided as input to the TDCALL[TDG.MR.REPORT] function. Lastly, the entire header is protected by an HMAC, ensuring the integrity of the TEE_TCB_INFO and TD_INFO components. The TEE_TCB_INFO structure contains details regarding the SVN and measurements of the TDX Module. In contrast, the TD_INFO has TD attestable properties, such as the initial TD configuration and values of the measurement registers.

Deriving a Quote

The TD report needs to be converted into a quote to enable verification by a third party outside the platform. TDX leverages the remote attestation mechanism of SGX for this purpose. The TD initiates a call to request the Quoting Enclave (QE), which operates on the host platform, to sign the TD report. Depending on the platform's quoting service implementation, this call can be made through VSOCK or TDCALL[TDG.VP.VMCALL].

After receiving the request, the QE uses the EVERIFYREPORT2 instruction to verify the HMAC protection of the TD report. If the verification succeeds, the QE uses its certified attestation key to sign the TD report, creating a quote digitally. This operation effectively replaces the MAC integrity protection of the TD report with digital signature protection. Consequently, any party can verify the authenticity and integrity of the quote using public key certificates. This quote can then be used for remote attestation, enabling external entities to verify the legitimacy of the TD and the platform's Trusted Computing Base (TCB) versions and software measurements.