docs: mention TDX in architecture descriptions

Everywhere we mention specifics on SNP, we should also mention the
correspondings specifics for TDX.

docs/docs/architecture/attestation.md

@@ -39,8 +39,8 @@ The root filesystem contains all  components of the container's runtime environm
 In the userland, the guest agent takes care of enforcing the [runtime policy](../components/overview.md#runtime-policies) of the pod.
 While the policy is passed in during the initialization procedure via the host, the evidence for the runtime policy is part of the CPU measurements.
 During the [deployment](../deployment.md#generate-policy-annotations-and-manifest) the policy is annotated to the Kubernetes Pod resources.
-On AMD SEV-SNP the hash of the policy is then added to the attestation report via the `HOSTDATA` field by the hypervisor.
-When provided with the policy from the Kata host, the guest agent verifies that the policy's hash matches the one in the `HOSTDATA` field.
+The hypervisor adds the hash of the policy to the attestation report via the HOSTDATA (on AMD SEV-SNP) or MRCONFIGID (Intel TDX) fields.
+When provided with the policy from the Kata host, the guest agent verifies that the policy's hash matches the one in the `HOSTDATA`/`MRCONFIGID` field.
 
 In summary a Pod's evidence is the attestation report of the CPU that provides evidence for runtime environment and the runtime policy.
 
@@ -92,7 +92,7 @@ By validating the runtime environment and the policies enforced on it, Contrast
 
 ### How does Contrast ensure the security of the attestation process?
 
-Contrast leverages hardware-rooted security features such as AMD SEV-SNP to generate cryptographic evidence of a pod’s current state and configuration.
+Contrast leverages hardware-rooted security features such as AMD SEV-SNP or Intel TDX to generate cryptographic evidence of a pod’s current state and configuration.
 This evidence is checked against pre-defined appraisal policies to guarantee that only verified and authorized pods are part of a Contrast deployment.
 
 ### What security benefits does attestation provide?

docs/docs/components/policies.md

@@ -36,10 +36,10 @@ These constitute the policy's *OCI data*.
 ## Evaluation
 
 The generated policy document is annotated to the pod definitions in Base64 encoding.
-This annotation is propagated to the Kata runtime, which calculates the SHA256 checksum for the policy and uses that as SNP `HOSTDATA` for the confidential micro-VM.
+This annotation is propagated to the Kata runtime, which calculates the SHA256 checksum for the policy and uses that as SNP `HOSTDATA` or TDX `MRCONFIGID` for the confidential micro-VM.
 
 After the VM launched, the runtime calls the agent's `SetPolicy` method with the full policy document.
-If the policy doesn't match the checksum in `HOSTDATA`, the agent rejects the policy.
+If the policy doesn't match the checksum in `HOSTDATA` or `MRCONFIGID`, the agent rejects the policy.
 Otherwise, it applies the policy to all future `AgentService` requests.
 
 ## Guarantees
@@ -66,12 +66,12 @@ Contrast verifies its confidential containers following these steps:
 1. The Contrast CLI generates a policy and attaches it to the pod definition.
 2. Kubernetes schedules the pod on a node with the confidential computing runtime.
 3. Containerd invokes the Kata runtime to create the pod sandbox.
-4. The Kata runtime starts a CVM with the policy's digest as `HOSTDATA`.
+4. The Kata runtime starts a CVM with the policy's digest as `HOSTDATA`/`MRCONFIGID`.
 5. The Kata runtime sets the policy using the `SetPolicy` method.
-6. The Kata agent verifies that the incoming policy's digest matches `HOSTDATA`.
+6. The Kata agent verifies that the incoming policy's digest matches `HOSTDATA`/`MRCONFIGID`.
 7. The CLI sets a manifest in the Contrast Coordinator, including a list of permitted policies.
 8. The Contrast Initializer sends an attestation report to the Contrast Coordinator, asking for a mesh certificate.
-9. The Contrast Coordinator verifies that the started pod has a permitted policy hash in its `HOSTDATA` field.
+9. The Contrast Coordinator verifies that the started pod has a permitted policy hash in its `HOSTDATA`/`MRCONFIGID` field.
 
 After the last step, we know that the policy hasn't been tampered with and, thus, that the workload matches expectations and may receive mesh certificates.
 

docs/docs/components/runtime.md

@@ -31,7 +31,7 @@ spec:
 ## Node-level components
 
 The runtime consists of additional software components that need to be installed
-and configured on every SEV-SNP-enabled worker node.
+and configured on every SEV-SNP-enabled/TDX-enabled worker node.
 This installation is performed automatically by the [`node-installer` DaemonSet](#node-installer-daemonset).
 
 ![Runtime components](../_media/runtime.svg)