Trusted Computing Base Recovery of Intel Trusted Execution Environments

Introduction

Intel employs a range of vulnerability management and response tactics, working across the industry to develop, validate, and disclose mitigations for vulnerabilities, addressing security risks that may affect Intel products.

In line with a public security first pledge, Intel is committed to continuous improvement in its product security posture by investing in strengthening the security of its processors and releasing updates and mitigations so customers can benefit from enhanced product security assurance.

From the time a security issue is reported to when a mitigation is released, Intel follows a multi-stage process to evaluate the vulnerability and determine an appropriate mitigation; validate and deploy the mitigation as part of coordinated vulnerability disclosure; and, in the case of confidential computing technologies, this process has to be further enhanced to provide the evidence that the latest mitigation update to the Trusted Execution Environment (TEE) Trusted Computing Base (TCB) has been deployed.

Intel employs a Trusted Computing Base Recovery (TCB-R) process that enables users to verify that the latest updates have been deployed, make security decisions, and establish or re-establish trust with the platform. This article focuses on the TCB-R process for Intel technologies, including policies and guidance for attestation.

Key terms used throughout this article are defined in the Glossary.

Overview of Trusted Computing Base Recovery

Trusted Computing Base (TCB) Recovery is a process that restores the integrity and functionality of the TCB after a compromise. The goal is to quickly and effectively return the system to a secure state. The TCB-R process has three stages: vulnerability handling, deployment and disclosure, and remote attestation.

Note Stages and activities may or may not overlap.

Vulnerability Handling

Intel's Product Security Incident Response Team (PSIRT) manages identification, assessment, and disposition of risks associated with security vulnerabilities in Intel products. When a suspected vulnerability is reported internally or externally, it will be triaged to confirm whether it is indeed a security issue. If confirmed, PSIRT will engage one or more engineering teams to determine the severity via a CVSS score as well as design the mitigation. Each engineering team will deliver an updated version of their respective ingredients that combine to fully address the issue.

Deployment and Disclosure

Each mitigation includes an updated ingredient list (BIOS, microcode, software, or firmware) that serves as input to an integration and validation process used to confirm mitigation effectiveness. When ingredients have met release criteria, they will be released to customers for preview and deployment, and then to the public with appropriate documentation.

After public disclosure, the ecosystem can obtain public microcode security releases from Intel's GitHub*. Confidential computing technologies such as Intel® Software Guard Extensions (Intel® SGX) and Intel® Trust Domain Extensions (Intel® TDX) may need extra steps depending on whether TCB components require a security update. Mitigation updates for Intel SGX and Intel TDX can be found in the Best Known Configuration (BKC) kit on the Intel Resource and Document Center (RDC). Specific RDC numbers can be found in Intel Platform Update collection guidance documents.

Remote Attestation

After the update has been applied by the infrastructure provider, a relying party also may need to take actions to verify that the platforms on which their TEE is running meet their desired security threshold. This verification is done through a remote attestation process. For each Intel Platform Update release, infrastructure providers should consult the TCB Recovery Attestation table for affected processors that require a TCB recovery.

Intel enables relying parties to verify mitigations that have been applied by an infrastructure provider through publication of signed information on an Intel-provided service. This information is published shortly after public disclosure at a date called the TCB-R event.

See Appendix: Intel TCB-R Components for a description of the components that comprise the Intel SGX and Intel TDX Trusted Computing Base. The security levels of components are tracked via Security Version Numbers (SVNs), which are the primary means of differentiating new versions of components in the TCB. The Remote Attestation Process section covers this in detail.

Trusted Computing Base Recovery Learnings

Since the launch of Intel Software Guard Extensions (Intel SGX) in September 2015 and continuing with Intel Trust Domain Extensions (Intel TDX), security and functional improvements have resulted in the need for ongoing TCB recoveries. Below are some lessons learned with the ecosystem that are worth understanding. These issues influence policies, practices, and considerations of Intel and its customers in how TCB Recovery is handled.

Ecosystem Deploys Updates at Different Rates

While Intel creates a variety of platform component updates to mitigate issues as they arise, in most cases there is not a path to update the platform directly. Intel relies on BIOS vendors, OEMand ODMs, OS vendors, and platform owners to update platforms in the field. The speed at which these parties can consume and distribute updates varies. Additionally, owners of an Intel SGX enclave or an Intel TDX trust domain (TD) need to update their software if mitigation of a security issue requires changes to these components.

Timing Constraints for TCB Recovery

Intel provides regular updates to products through the Intel Platform Update process, as well as updates through maintenance releases (MRs) and post-launch releases (PLRs) for products that are earlier in their post-PV lifecycle. Updates to Intel SGX and Intel TDX TEE TCBs are part of this process. Issues found internally by Intel constitute the majority of mitigations and often have additional flexibility in scheduling public disclosure, which can provide customers with increased predictability and flexibility while preserving timeliness.

Timelines for issues reported by external security researchers, including public disclosure, are less able to be influenced by Intel. External researchers often wish to publish findings aligned with a security conference or some other deadline. Intel works with the security research community through coordinated vulnerability disclosure to navigate the complexities of delivering comprehensive packages against tight deadlines, but sometimes those deadlines are inflexible.

Platform Reset Timing Impact

Multiple components are involved in a hardware TEE, and mitigations for some issues may require a platform reset to be fully effective. This can cause challenges for service providers who must contact tenants to move workloads to updated platforms, resulting in service interruptions, further adding to the time it takes to fully deploy updates.

Intel works with ecosystem partners to create architectural features, such as TD Preserving Updates for Intel TDX or EUPDATESVN for Intel SGX, to reduce the cases where a full platform reset is required. For more, see the Security Updates section.

Security Configuration Trade-off

Not all mitigations can be applied by default. How a platform is configured, including whether optional security mitigations are enabled, affects the security of the platform. With Intel SGX, mitigations for security issues are typically implemented in hardware, microcode, or xucode. In cases where system software can enable and disable security mitigations, which may impact an enclave, such mitigations will typically be enabled for code inside an enclave. For example, the bits represented by the IA32_MCU_OPT_CTRL MSR can be disabled for code outside the enclave but not inside.

For configurations that cannot be changed at runtime, the default is to only allow the most secure configuration when Intel SGX is enabled. An example of this is that legacy APIC mode can’t be used with Intel SGX enabled on Sapphire Rapids platforms. There are exceptions to this default behavior. When exceptions are made, configurations must be attestable, so that relying parties can distinguish attesting platforms with the most secure configurations from those with less secure ones.

Some Updates May Not Require TCB Recovery

Similarly, some updates may resolve issues that Intel does not believe to be a real-world security concern, such as bugs that are not exploitable but are fixed out of an abundance of caution. In such cases, Intel may update the SVN without needing a TCB-R. If any part of these updates is later determined to have a security impact, this allows Intel to issue a TCB-R update at a later time without requiring the ecosystem to deploy a new update.

Security Updates

Intel is at the forefront of developing capabilities to perform security updates while platforms are actively supported. These update capabilities are independent from the attestation capabilities; the platform can be updated to correct issues, but attestation will not reflect this fact until TCB-R is completed. Additionally, performing an update does not revoke or invalidate previous attestations. Attestations can continue to be used and should be interpreted as a statement that the platform is at least updated to the configuration reflected in the attestation.

Depending on the update, TCB-R might or might not require a full platform reset. If a reset is not required, OS Patch Loading (OSPL) can be used.

The next sections discuss TCB-R that can occur at runtime without disrupting platform software and those that require a platform reset to fully complete the recovery process.

Seamless Runtime TCB Recovery

Intel TDX supports TD Preserving Updates.1 This update variant allows most platform components to be updated while allowing TD operation to continue generally unaffected.

TD attestation includes two TCB levels: the level at the time the TD was created and the current TCB level of the platform. Some relying parties will evaluate the TD based exclusively on the creation-time TCB level, since this establishes the baseline for the TD. As a result, these relying parties may not establish trust when they perform remote attestation after a seamless runtime TCB-R was performed. These relying parties would require a restart of the TD. Other relying parties may take into account both TCB levels to establish trust in TDs with an older TCB level when the TD was created and a newer current TCB level. These relying parties accept that the TD executed for some time with known vulnerabilities but has since been mitigated.

For Intel SGX, remote attestation only reflects the TCB level when the enclave was created. Microcode updates can be loaded via OSPL when enclaves are present and being used, resulting in a more robust platform, but enclave attestation will not reflect the update. To create enclaves that attest to the new TCB level following an update, all enclaves must be torn down, the EPC emptied, and the ENCLS[EUPDATESVN] instruction executed. After these steps, newly launched enclaves will attest to the updated TCB level.

Intel TDX attestation is an extension of Intel SGX attestation. As a result, platforms using Intel TDX follow the same Intel SGX TCB-R process and guidelines.

OSPL-based updates for Intel SGX and Intel TDX require OS software enabling, which is not available for all OSes. For those without support, a platform reset may be required to update the enclave or TD attestation.

Warm Reset TCB Recovery

Any vulnerabilities that can be mitigated by seamless runtime TCB-R but the OS does not support seamless runtime update can be mitigated with a warm reset. However, the mitigation must be applied by the OS prior to using Intel SGX or Intel TDX.

BIOS Required TCB Recovery

Many vulnerabilities can be mitigated with runtime updates and the mitigations are fully effective. Some vulnerabilities either cannot be effectively mitigated with a runtime update or the mitigation cannot be reflected in remote attestation without resetting the platform. For example, some TCB components are only loadable by the BIOS, including BIOS time microcode and Authenticated Code Modules (ACM) that, due to their nature, must be applied early during the platform boot.

TCB Recovery Examples

Comparable to the consolidated Affected Processors table, which lists the security status and action required for Intel processors to mitigate security vulnerabilities, the TCB Recovery Attestation table presents the latest security status and action required for impacted Intel processors to complete TCB-Recovery. Additionally, the table indicates whether a platform reset is necessary or if a runtime update is sufficient to perform remote attestation at the new TCB level. The following table shows common examples of cases that require a reset and cases that do not require a reset.

Table 1. Examples of security mitigations with acceptable runtime updates and reset required for Intel SGX.

Table 2. Examples of security mitigations with acceptable runtime updates and reset required for Intel TDX and Intel® Trusted Execution Technology (Intel® TXT).

Remote Attestation Process

The security landscape is ever-evolving. Practices for designing and building secure systems need to be constantly revised to incorporate the latest defense-in-depth techniques, address emerging vulnerabilities, and guard against new threats. Remote attestation is the process of generating evidence that a verifier confirms a Trusted Execution Environment’s (TEE) identity and TCB level.

Intel hardware-based TEEs, Intel SGX, and Intel TDX, are designed to cryptographically prove that a system’s Trusted Computing Base (TCB)—all hardware, firmware, and/or software components that are critical to security—is updated to the latest TCB level, including its latest security updates.

A TEE can create and provide attestation evidence, called a quote, to maintain hardware as the root of trust. Intel SGX Data Center Attestation Primitives (DCAP) and Intel TDX equivalent is software that can be used for quote generation. A relying party can use any verification solution to validate the quote using Intel signed verification collateral provided by the Intel Software Guard Extensions Provisioning Certification Service and/or Intel Trust Domain Extensions Provisioning Certification Service. The quote contains the TCB level of the TEE, which can be compared against verification collateral to determine disclosed vulnerabilities that have been mitigated.

For every TCB-R event, Intel provides new Provisioning Certification Key (PCK) certificates and new verification collateral after public disclosure. This information is published by the provisioning certification service for Intel SGX and Intel TDX, respectively. PCK certificates contain a new key that allows a platform to prove that the platform is at a certain TCB level. Verification collateral lists the trust status for each TCB level. A relying party compares the TCB level indicated by the PCK certificate with the TCB level in the verification collateral to establish trust in the platform.

If the TCB level indicated by the new PCK certificates is greater than or equal to the TCB level added to the new verification collateral, then new mitigations associated with this TCB-R event have been applied.

The PCK certificate is requested by the host platform and verification collateral is requested by the Verifier (Attestation Service Provider). Before obtaining a new or updated PCK certificate, the host platform would need to have the latest security update. Specific steps include:

1. Attestation Request: Relying parties must request attestation in the form of a new quote (evidence of compliance) from the TEE.

2. PCK Certificate Requested: Platform requests PCK Certificate for the newest TCB level. This is required for quote generation.

3. PCK Certificate Delivered to Platform: Provisioning certification services for Intel SGX and Intel TDX provide the PCK Certificate corresponding to the request. This is required for quote generation.

4. Quote Generation: The TEE in the host (attesting) platform uses the new PCK certificates to generate evidence (Quote) to prove that mitigations included in the latest TCB-R were applied.

5. Forward Quote: Quote (evidence of compliance) is sent to the Verifier.

6. Verified Results: The Verifier (Attestation Service) uses new verification collateral to evaluate the Quote signature and claims in the Quote to ensure that mitigations were applied. For a complete security update, it is important for the relying party to have trust in the Verifier they are using. Intel provides an independent attestation service as part of Intel® Trust Authority.

7. Trusted Transaction: Data exchange can be done with trust.

When requesting TCB verification collateral from the provisioning certification services for Intel SGX and Intel TDX, the Verifier can specify the currency of the information it receives by passing one of two values for the ‘Update’ parameter:

Update = “early”: Verification collateral contains the TCB level of the latest TCB-R event. This enables the most security-conscious parties to check their infrastructure’s TCB level as soon as possible. The TCB level is usually made available at public disclosure for vulnerabilities that have mitigations included in the recovery. Verification collateral and new Provisioning Certification Key (PCK) certificates are issued by the provisioning certification service for Intel SGX and Intel TDX, respectively.

• The infrastructure provider or CSP must deploy the latest security updates from each Intel Platform Update and re-register their platform with Intel before an updated PCK certificate can be generated.
• A TCB-R counter (also known as tcbEvaluationDataNumber, contained in the TCB Info structure) is assigned to all verification collateral. A relying party can use this TCB-R counter to determine which verification collaterals the verifier used when it generated a verification result. This TCB-R counter is incremented for each TCB-R event. As a result, a relying party knowing the latest TCB-R counter can be sure that the latest mitigations are applied.
• For Intel SGX, the latest TCB-R counter can be obtained from the data returned by the Get SGX TCB Info API of the Intel SGX provisioning certification service and the optional update parameter set to ‘early’. Intel TDX information can be retrieved in a similar way from Get TDX TCB Info web service. Family/Model/Stepping/Platform/Custom (FMSPC) detail is retrieved from PCK certificates. All FMSPC will return the same TCB-R counter.
• Having the input parameter [Update] set to “early” returns the highest TCB-R counter, indicating the most recent TCB-R event.
• The Verifier compares evidence in the quote with the verification collateral it collects from the provisioning certification services for Intel SGX and Intel TDX to verify the identity of the TEE and determine its TCB level.
  • For example, if TCB level is at the latest, Verifier will return a TCB status of UptoDate or equivalent evaluation, indicating the latest mitigation is applied. If the TCB level is not the latest, the verifier will return mitigation OutofDate or equivalent evaluation.
  • Attestation status responses3 include: UpToDate, SWHardeningNeeded, ConfigurationNeeded, ConfigurationAndSWHardeningNeeded, OutOfDate, OutOfDateConfigurationNeeded, Revoked.
  • Consult the Get Intel SGX TCB Recovery Information documentation for a description of attestation status values.
• Custom trust policies can be set by either the relying party or verifier. The verifier implemented by Intel® Trust Authority supports custom policy. See the Guidance to Maintain Good Security Posture section for more information.

Update = “standard”: Verification collateral contains the TCB level of the TCB-R counter made available 12 months prior on the update = “early”. This is the collateral returned by default when the update parameter is not specified. See figure 3. Once the “standard” TCB-R counter has been incremented, Intel stops publishing verification collateral with previous TCB-R counter values.

Using standard is an easy way to implement a grace period, time after a TCB-R event that a relying party establishes trust in a platform that has not applied new mitigations.

Intel does not usually revoke platforms running software and firmware not mitigated against disclosed vulnerabilities. Intel publishes certificates and verification collateral to allow the relying party to evaluate the TCB level. It is left to the relying party to determine whether they will establish trust with a platform that is not mitigated against disclosed vulnerabilities.

Ultimately, the verifier and relying party of any attestation are the entities making trust decisions about a quote. It is the responsibility of the verifier and relying party to set trust policies including any grace period.

 

Guidance to Maintain Good Security Posture

Intel is continuously improving its processors’ security posture providing regular updates and mitigations. Intel weighs many factors including our security-first pledge, prior learnings, impact to the ecosystem, and others in determining when to deploy and disclose security mitigations and our ongoing policy around TCB-R updates.

For trust to be established among different entities, systems need to be attested to be in a good state. Relying parties can establish trust with a Trusted Execution Environment (TEE)-enabled platform using remote attestation. For example, Intel TDX can be used to provide protected VMs for tenant workloads and Intel SGX can protect workloads inside a VM.

Following are basic elements to consider for different roles.

Guidance to Infrastructure Providers

Infrastructure providers (cloud service providers or equivalent) are not required to deploy all available mitigations by public disclosure of each Intel Platform Update release. However, infrastructure providers should provide clear documentation on the potential applicability of published issues to their infrastructure as well as policy documentation regarding their update cadence and available tenant options.

Applying mitigations can be a complex endeavor and may not be feasible in the time prior to a TCB-R event. If an infrastructure provider cannot apply mitigations during the deployment phase, the provider can have a policy covering the time between the mitigation and TCB -R events, called a grace period. The policy used to cover this gap should be provided to tenants or relying parties and should be supported by the verifier.

Some examples of custom policies could be:

• The most security conscious customers may not allow a grace period and require strict adherence to the update = Early timing.
• Other customers may be comfortable allowing a mitigation grace period, enabling the application of mitigations after a TCB-R event while still establishing trust. Examples of mitigation grace periods could include:
  • Use update = Standard instead of Update=Early to retrieve verification collateral. This gives a full 12-month mitigation grace period.
  • Use update = Early to retrieve verification collateral and allow an out-of-date TCB level status for some time period less than 12 months.
• Additional platform claims:
  • A custom policy might allow a successful appraisal of attestation results considering platform configuration, specific Security Advisory IDs, or other platform claims.

The following options can be used for custom appraisal policy setup:

• Intel® Tiber™ Trust Authority
• Attestation Overview
• Platform TCB Policy
• Policy Builder Tool

 

• Intel® SGX Data Center Attestation Primitives (Intel® SGX DCAP) software with attestation appraisal source code, samples, and documentation are available:
  • Intel SGX DCAP on GitHub
  • Appraisal Engine sample (located in the Intel SGX DCAP software branch)
  • Appraisal Engine Developer Guide

Guidance to Relying Parties and Tenants Using an Infrastructure Provider

Relying parties and tenants of an infrastructure provider (CSP) can understand security posture, assess risks, and establish trust by examining the TCB level and TCB-R counter of the verification collateral. Before a tenant’s workload is instantiated on a virtual machine/Trust Domain provided by a CSP, it is important to attest that it is trustworthy. Relying parties should understand the policies set by the infrastructure provider and implemented by a verifier. Verifier attestation results should include enough information for a relying party to make this trust decision.

Common understanding between relying parties and the infrastructure provider is important. A level of flexibility is required without compromising trust. Mitigating against vulnerabilities could be difficult, so a platform being slightly out of date compared to the latest mitigations may not be a reason to limit the trust relationship between parties. Many infrastructure providers implement their own policies regarding the frequency of updates to balance security risk with business continuity. Tenants should consider their risk profiles and use all available data to make trust decisions. If security is of the highest priority, tenants should strongly consider whether leveraging an independent attestation service verifier such as Intel Tiber Trust Authority increases their confidence.

Guidance to Attestation Service Providers

Collaborate with hardware vendors on security updates and to provide relying parties the flexibility to apply appropriate trust policies. Cloud providers can leverage an independent verification service such as Intel Tiber Trust Authority to verify attested systems within their infrastructure. The attestation provider is responsible for comparing the quote (evidence) against verification collateral. The output is an attestation result which includes any trusted policies used by the attestation provider. This allows a relying party to know which trust policies are used and the effect of the trust decision. For example, the attestation provider may provide a grace period policy to allow a hardware vendor more time to apply mitigation after TCB-R event. They may use verification collateral with an older TCB-R counter.

Glossary

Grace Period: Time after a TCB-R event (incremented TCB-R counter, new verification collateral/PCK certificates) that a relying party establishes trust in a platform that has not applied the new mitigation.

Quote: Intel’s nomenclature for remote attestation evidence. Based on RFC9334 Remote Attestation Procedures (RATS) Architecture. Evidence is defined as a set of claims about the Target Environment that reveal operational status, health, configuration, or construction that have security relevance.

Reset: Generally, consists of shutting down the OS or VMM and issuing either a warm or cold reset to the system. A warm reset flow does not need to fully re-initialize the platform. It is generally faster than a cold reset flow. A cold reset flow initializes all the components in a platform. For example, retraining buses and initializing memory.

Remote Attestation: Another name for the TCB-R recovery process by which a peer (attester) produces believable information about itself (evidence) to enable a remote peer (relying party) to decide whether or not to consider that attester a trustworthy peer.

Security Version Numbers (SVN): Value representing ‘security worthiness’ of a component used in the Trusted Computing Base (TCB) of a Trusted Execution Environment (TEE). For Microcode Updates (MCU) it is often referred to as the "anti-rollback ID." When loading an MCU (WRMSR 0x79) the new value is compared with the current value to prevent loading an MCU with a lower SVN. When an MCU is released to address security issues, the SVN may be incremented to prevent loading of an older, potentially vulnerable, MCU.

Trusted Computing Base (TCB): All hardware, firmware, and/or software components that are critical to implement the security objectives of Intel SGX and Intel TDX.

TCB Information: Verification collateral published by a provider containing a collection of TCB levels, each associated with a TCB-Recovery event indicating mitigations for disclosed vulnerabilities.

TCB Level: Array of TCB components and their corresponding SVN numbers that together help describe security of a platform.

TCB Recovery (TCB-R): Process for restoring the integrity and functionality of the TCB after a compromise.

TCB-R Counter: Another name for the tcbEvaluationDataNumber contained within verification collateral. The number is incremented for each TCB-R event (the highest number being most recent) and can be used to determine the most recent verification collateral to use for quote verification.

TCB-R Event: The date at which Intel publishes Provisioning Certification Key certificates and verification collateral shortly after public disclosure of the mitigation.

References

Intel SGX 101: Attestation

Intel SGX Enclave Overview

IETF: Remote Attestation Procedures Architecture Memo

Intel SGX Trusted Computing Base Recovery

Intel TDX specification

Appendix: TCB Components

The XuCode technical article outlines components in the Intel SGX TCB. The Intel TDX TCB contains additional components. Table 3 identifies some common TCB components.

Note that the content inside Intel SGX and Intel TDX is not in scope for TCB-R. Every component is being explained in the following section.

Table 3. TCB components list for Intel SGX and Intel TDX in the Best Known Configurations (BKC) kit

TCB Components	Intel SGX TCB	Intel TDX TCB
MCU	Yes	Yes
Intel TDX Loader4	NA	Yes
Alias Check Trusted Module (ACTM)	Yes	Yes
BIOS Guard Module and Legacy ACMs	Yes	Yes
Intel TDX Module	NA	Yes
Quoting Software5	Intel SGX/Intel TDX remote attestation	Intel SGX/Intel TDX remote attestation
Migration TD	NA	Migratable TDs Only
SINIT	Yes	Yes

Unified Microcode Update (MCU)

The Unified Microcode Update (MCU) contains updates to a number of sub-elements (including microcode, XuCode, and MCHECK) that can be involved in the TCB Recovery, as well as firmware for other IPs in the CPU.

Microcode updates can be instantiated at a number of points in the platform lifecycle.

Intel® Trust Domain Extensions (Intel® TDX) Loader

The Intel TDX Loader, also known as SEAMLDR, consists of two parts: the Non-Persistent SEAM Loader (NP-SEAMLDR) and the Persistent SEAMLDR (P-SEAMLDR). The NP-SEAMLR is an ACM, which loads the P-SEAMLR into memory. The P-SEAMLR in turn loads the Intel TDX Module into memory.

Alias Check Trusted Module (ACTM)

The Alias Check Trusted Module (ACTM) is directly in the Intel SGX and Intel TDX TCB, as it detects aliases in system memory addresses. Typically, the ACTM is deployed as part of the BIOS image and invoked during the initial platform boot and is part of Authenticated Code Modules.

BIOS Guard and Legacy Authenticated Code Modules (ACMs)

There are several other non-Intel SGX/non-Intel TDX ACMs that different technologies use, including Intel® BIOS Guard and Intel® Trusted Execution Technology (Intel TXT). These are placed in the TCB as a precaution in case their additional privileges could be used in an attack. They are often, but not always, distributed with the BIOS image.

Intel TDX Module

The Intel TDX module enables Intel TDX and is the runtime code that is a peer to the VMM and supports Trust Domains. It executes in SEAM (Secure Arbitration Mode) and is responsible for providing TD security.

The main distribution channel of the Intel TDX Module is through the BIOS image. Additionally, the Intel TDX Module can be updated manually via a binary deployment.

Quote Generation Software

Quote Generation Software is installed on the platform and works by wrapping the Quoting Enclave (QE) and Provisioning Certification Enclave (PCE), both written and signed by Intel and distributed as part of Intel SGX DCAP. For some vulnerability mitigations, an updated QE and/or PCE is needed. In such a case, Intel creates, signs, and provides new versions.

Migration TD

Intel TDX supports the ability to migrate TDs between TDX-supporting platforms. Example uses include load management or emptying platforms in need of maintenance. To aid in determining whether a potential migration destination meets the security requirements of the TD owner, Intel TDX architecture uses Migration TD to authenticate and evaluate destinations. Each migratable TD has a Migration TD bound to it at creation time that is part of its TCB. Intel provides a reference Migration TD. For more information see Intel TDX Migration TD Design Guide.

Security Initialization (SINIT)

There are two types of authenticated code modules provided for boot security. Intel TXT uses a BIOS ACM to provide a static root of trust for measurement and a SINIT ACM to provide a dynamic root of trust for measurement for late launch of the VMM or host OS. Boot Guard uses the BIOS ACM to provide a static root of trust for verification and measurement.

Footnotes

1. TD Preserving Update is a feature that allows the TDX Module to be updated at runtime, minimizing TD interruption and preserving TD State
2. Special Intel SGX enclave provided by Intel
3. These are the supported values for the tcbStatus properties in the TcbInfoV3 JSON object
4. Also known as SEAM Loader (SEAMLDR)
5. Intel SGX Attestation Enclave