Workload 0xff12829b3f3c374f975037e0d966132ec536fc7df178aecf06882b8c106c5732

You select the workload ID. This report does not check its current on-chain capability assignment.

Workload ID being checked: 0xff12829b3f3c374f975037e0d966132ec536fc7df178aecf06882b8c106c5732

Check the provenance record and confirm that its eight measurement values produce the selected workload ID.

• Eight measurements hash to the workload IDverified
  Technical details

  MRTD	0xc1ee9c16e3afc506cfe042c5b846a368528f3b37618eafb27469bc114cf914e9222c91618470e7f2b28ac360968270a5
  RTMR0	0xb87ca0be65abc7c1c5f113366cea51c160b75dcb0483b139f624ac78e65015172e08079d418d4934ac81a03c3d7c48b5
  RTMR1	0x8ee95b11b5ed33ef2a0e3bf3cb2ccab6806b3b532b4495449c1b7e58d659f6ad7d784c6f3d7238f36379e01c6f6f06e2
  RTMR2	0xdea463d239f5371d70003cd0716207361db706eb5623451add0b5079e666d376b7edb22fcc65b19394c78fa770052760
  RTMR3	0x80217d1737da04d998c735065d5f4a8ed850da65598d2bd8bb32e6df9d9342d1983734014cb3e186efb13abde4e002d8
  MRCONFIGID	0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  XFAM	0xe702060000000000
  TD attributes	0x0000001000000000

  keccak256(mrTd || rtMr0 || rtMr1 || rtMr2 || rtMr3 || mrConfigId || xFAM || tdAttributes)
= 0xff12829b3f3c374f975037e0d966132ec536fc7df178aecf06882b8c106c5732 ✓

Use the verified prebuilt OS image, Docker images, Docker configuration, and TDX boot profile to recompute the eight TDX values. Compare each value with the expected measurements from step 2.

Verify the prebuilt OS image

This check links the published OS artifact to its recorded source repository, commit, and build instructions. The service hashes the build instructions and OS artifact, compares them with the provenance manifest, and confirms that the recorded source and artifact values match an immutable platform-profile bundle selected from the service-owned accepted-profile registry. The workload record names the selected profile’s opaque ID; the registry binds that ID to the exact archive. Each check below links the exact files and source used, so you can inspect them or repeat the comparisons.

For GCP/mkosi, the provider profile is accepted in a separate offline phase, where the service rebuilds the recorded ritual-images source commit and confirms that the rebuilt guest disk matches the published image.

• 1. Build instructions match the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the recorded OS build instructions and compares it with the expected digest in the provenance manifest. The evidence link below is the exact file used, available if you want to repeat the comparison.

  Expected SHA-256 digest from the manifest:
  sha256:e8346b4e2751eba2e5ac1711e8663c970dbecb1fc928d5d7e1f4cdeff5591518

  Related evidence and source:

  • OS build instructions
• 2. OS image matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the prebuilt OS image and compares it with the expected digest in the provenance manifest. The evidence link below is the exact image used to reproduce the TDX measurements, available if you want to repeat the comparison.

  Expected SHA-256 digest from the manifest:
  sha256:e4555e4f35240a8d3f3f0a136ed77a75387b2ea462541ef01038db41290a6695

  Related evidence and source:

  • OS image
• 3. OS artifacts match accepted offline measurementsverified
  Technical details

  This check confirms that the repository, commit, build instructions, and published OS image in the manifest are consistent with the values that were accepted after a reproducible offline OS build. The evidence and source links below show the exact values used, available if you want to inspect or repeat that build.

  Related evidence and source:

  • OS build instructions
  • OS image
  • GCP TDX machine profile
  • ritual-net/ritual-images @ 6d760b945f0023e1b82b05df66cac4b87d8de73b

Verify the Docker workload configuration used in the TDX measurements

This check links the Docker workload inputs to the TDX measurements that commit to them. The service checks the exact measured configuration against its manifest digest, extracts its digest-pinned container images, and confirms that the image list exactly matches the Docker images declared in the manifest. This means the GitHub attestations in step 4 cover the container images committed to the TDX measurements. The provider-specific details below explain which configuration is measured and how it contributes to the TDX values.

For GCP/mkosi, the measured configuration is the exact labeled byte stream containing the environment file followed by the Docker Compose file. Here, we are validating the connection between docker images -> full configuration, which can then be connected to the RTMR3 value. The service publishes the measured byte stream and both component files so you can inspect the exact inputs or repeat the calculation.

• Docker configuration matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the Docker configuration bytes from the uploaded evidence bundle and compares it with the expected digest in the provenance manifest. The service publishes the exact verified bytes linked below.

  Expected SHA-256 digest from the manifest:
  sha256:dd56bb99ebda061a28cdc46a39a49bd6b3125c84f9a0009887e482455c403fe1

  Related evidence and source:

  • Docker configuration
• Environment file matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the environment file from the uploaded evidence bundle and compares it with the expected digest in the provenance manifest. The service publishes the exact verified file linked below.

  Expected SHA-256 digest from the manifest:
  sha256:e9d81f49762c35e6b4f953ddf7a9178a9afd2af01caf3b872bca0faa80bd190d

  Related evidence and source:

  • Measured environment
• Docker Compose file matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the Docker Compose file from the uploaded evidence bundle and compares it with the expected digest in the provenance manifest. The service publishes the exact verified file linked below.

  Expected SHA-256 digest from the manifest:
  sha256:08f6c1d196f20fd39af071ba07f8079cabef203d0a48499df4fd5ca731b62e5b

  Related evidence and source:

  • Measured Docker Compose file
• Container images match the RTMR3 configuration measurementsverified
  Technical details

  This check connects the exact Docker configuration bytes measured into RTMR3 to the container images declared by the provenance record.

  1. The Docker configuration is a binary-safe byte stream containing a labeled copy of the environment file followed by a labeled copy of the Docker Compose file. It uses a .bin extension because it preserves the exact measured bytes rather than representing one standalone text format.

     ritual-container-env\n
     + raw environment bytes
     + ritual-container-compose\n
     + raw Compose YAML bytes

  2. Parse the Compose YAML and inspect every service under the top-level services mapping. This validation requires every service to specify a direct, digest-pinned image and rejects build directives, includes, extends, YAML indirection, and duplicate keys.
  3. Compare the parsed image list with the Docker images declared in the provenance manifest. Recall that the provenance manifest is the central index for this workload. It records the expected TDX measurements, the locator and digest of each verification artifact, and the repository and commit for relevant source code. Missing, additional, or different images cause a mismatch.

  Related evidence and source:

  • Docker configuration
  • Measured environment
  • Measured Docker Compose file

Verify the TDX boot profile

The TDX boot profile is the provider-specific recipe that combines the selected VM image with the cloud platform’s firmware, virtual-machine configuration, VMM behavior, and TDX launch settings to reproduce the boot-related measurements. This check links the boot-related TDX measurements back to the boot profile that produced them. The service verifies the supplied artifacts against the provenance manifest and requires the provider-specific profile values to match an accepted provider profile.

For GCP/mkosi, the accepted boot profile connects MRTD to the exact Google OVMF firmware and machine topology. It also supplies the calibration baseline used with the OS image’s UKI and GPT disk layout to calculate an expected RTMR1. The workload CCEL separately records the boot events observed for RTMR0, RTMR1, and RTMR2. The complete-tuple procedure below performs both calculations and requires the two RTMR1 values to match. A different cloud provider, machine type, or firmware version requires a different accepted boot profile.

Google OVMF firmware + machine topology        → MRTD inputs
workload CCEL                                   → observed RTMR0, RTMR1, RTMR2
OS image UKI + GPT layout + accepted baseline   → expected RTMR1
offline-approved VMM launch configuration       → MRCONFIGID, XFAM, TDATTRIBUTES

• GCP TDX machine profile matches the offline-approved configurationverified
  Technical details

  This check covers the machine and boot-artifact values in the offline-approved GCP profile. The verifier requires the supplied machine type, memory topology, firmware, UKI, baseline, and disk hashes to exactly match the values accepted during offline calibration.

  Expected SHA-256 digest from the manifest:
  sha256:a27af23ac396382b7a8be8c3dc50e6ea89bb202e09585a4f46d3c2becabe20bb

  Related evidence and source:

  • GCP TDX machine profile
• GCP TDX VMM launch configuration matches the offline-approved configurationverified
  Technical details

  This check covers MRCONFIGID, XFAM, and TDATTRIBUTES. These values are determined by the VMM’s launch configuration—essentially VM creation flags—rather than derived from guest source code. The verifier requires them to exactly match the values accepted during offline calibration before using them in the reproduced TDX tuple.

  Expected SHA-256 digest from the manifest:
  sha256:a27af23ac396382b7a8be8c3dc50e6ea89bb202e09585a4f46d3c2becabe20bb

  Related evidence and source:

  • GCP TDX machine profile
• MRTD matches Google-endorsed OVMF firmwareverified
  Technical details

  This check connects the MRTD value back to the closed-source OVMF firmware binary. During offline profile acceptance, the service verifies Google’s signed launch endorsement and confirms that its endorsed OVMF firmware digest matches this binary. For this workload, the service checks the binary against the manifest and accepted profile, confirms that its SHA-384 identity matches the calibration baseline, and combines it with the recorded machine topology to reconstruct MRTD.

  Expected SHA-256 digest from the manifest:
  sha256:9b874b165572566e7f5e9970c47f0b0ee1dc9f8333861c3b9c1c6f4cf81446ca

  Related evidence and source:

  • Platform firmware
• GCP RTMR1 calibration baseline matches the accepted profileverified
  Technical details

  This check verifies that the calibration baseline file matches its digest in the provenance manifest and the baseline pinned by the offline-approved GCP profile. The baseline supplies the provider-specific measurement context that the pinned tool later combines with the exact UKI and GPT disk layout to calculate the expected RTMR1. That calculation and its comparison with the workload CCEL replay happen under Reproduce TDX measurements.

  Expected SHA-256 digest from the manifest:
  sha256:72dd2ded7682804829627bff77c1e11697d8b4d08965934200011ba6c82967b9

  Related evidence and source:

  • Calibration baseline
• CCEL evidence matches the manifestverified
  Technical details

  CCEL stands for Confidential Computing Event Log. It is the complete ordered record of boot events measured into the TDX runtime measurement registers. Google’s OVMF firmware determines which boot events are recorded, while GCP-supplied platform inputs determine some event contents and digests.

  The provenance evidence includes two logs:

  • The calibration CCEL was captured and replayed when the GCP boot profile was approved offline.
  • The workload CCEL is supplied for this workload and replayed during workload verification.

  The accepted offline profile binds the calibration CCEL. The workload CCEL is passed to the measurement tool when it reproduces this workload’s TDX measurements. Each file must match its own manifest digest. In this record, the digests are identical, so successful verification confirms that the measurement tool receives the same CCEL bytes accepted with the offline profile.

  Expected SHA-256 digest for the workload CCEL from the manifest:
  sha256:a54bf4702ae0a85788df8c8550467d8eb1c7b060515164d8dd359d2b35fbf870

  Expected SHA-256 digest for the calibration CCEL from the manifest:
  sha256:a54bf4702ae0a85788df8c8550467d8eb1c7b060515164d8dd359d2b35fbf870

  Related evidence and source:

  • Workload boot event log
  • Calibration boot event log

  We provide the calibration CCEL as an additional reference showing the boot-event structure observed when the TDX profile was accepted. Because parts of Google’s firmware and GCP platform are closed source, Google-controlled inputs such as ACPI data may change without advance public notice and produce different event digests, so workload events are not required to equal the calibration events. Strong evidence that the measurements came from a genuine Google TDX launch should instead come from provider-backed platform attestation bound to the specific TDX quote. The CCEL has a narrower role here: it preserves the ordered event chain and helps connect the resulting TDX measurements back to components and inputs that can be independently inspected or reproduced.

Reproduce TDX measurements

With the OS image, Docker configuration, and TDX boot profile established above, this section runs the provider-specific measurement procedure that ties them together. We use pinned binaries that calculate the resulting TDX measurements without needing to run a TDX machine, and link to their source code.

verified OS image + Docker configuration + TDX boot profile
                              ↓
                   pinned measurement tool
                              ↓
              recomputed eight-field TDX tuple
                              ↓
          canonical output digest matches manifest

For GCP/mkosi, the pinned cvm-measure implementation and Ritual adapter calculate MRTD from the endorsed firmware and machine topology, replay RTMR0, RTMR1, and RTMR2 from the workload CCEL, independently cross-check RTMR1 against the exact UKI and GPT disk layout, and extend RTMR3 with the SHA-384 digest of the Docker configuration.

• Measurement tool build instructions match the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the measurement tool’s build instructions and compares it with the expected digest in the provenance manifest. The evidence link below is the exact file identified by the manifest, available if you want to inspect how the tool is built or repeat the digest comparison.

  Expected SHA-256 digest from the manifest:
  sha256:4bd287c1907a731dbc0c198e828aa41ff51ee125c63abfe051b2e8092a280492

  Related evidence and source:

  • Measurement tool build instructions
  • cvm-measure source commit
• Measurement tool identity matches the accepted profileverified
  Technical details

  This check confirms that the measurement tool recorded in the manifest—its name, version, source repository, commit, executable digest, build instructions, and execution image—matches the tool selected by the accepted profile. The measurement worker is restricted to the approved executable when it runs the procedure.

  Related evidence and source:

  • Measurement tool build instructions
  • Measured environment
  • Measured Docker Compose file
  • Platform firmware
  • Calibration baseline
  • Calibration boot event log
  • Workload boot event log
  • GCP TDX machine profile
  • cvm-measure source commit
• Recompute the complete eight-field TDX tupleverified
  Technical details

  This check runs the provider-specific measurement procedure with the verified OS image, Docker configuration, and TDX boot-profile inputs from the preceding sections.

  1. Extract the GCP disk and embedded UKI from the verified prebuilt OS image, then confirm their hashes match the accepted profile.
  2. Calculate MRTD from the Google-endorsed OVMF firmware and the accepted machine topology.
  3. Replay the workload CCEL to reconstruct the RTMR0, RTMR1, and RTMR2 values produced by its recorded boot-event chains.
  4. Independently calculate the RTMR1 expected from the exact UKI, GPT disk layout, and offline-approved calibration baseline, then require it to equal the RTMR1 produced by the workload CCEL replay. This is the check that binds the observed boot log to the OS artifacts verified above; without it, the OS artifact checks and CCEL replay would only be separately consistent with the manifest.
  5. Start RTMR3 at 48 zero bytes. The accepted GCP boot CCEL contains no RTMR3 events, so there is no boot-time RTMR3 event chain to replay. The profile records the same zero value, which the verifier checks as a consistency guard.

     initial_RTMR3 = 48 zero bytes

  6. Hash the exact Docker configuration with SHA-384, then extend the initial RTMR3 with that digest to produce the final workload-specific RTMR3.

     configuration_digest = SHA-384(Docker configuration)
     final_RTMR3 = SHA-384(initial_RTMR3 || configuration_digest)

  7. Take MRCONFIGID, XFAM, and TDATTRIBUTES from the accepted machine profile to complete the eight-field TDX tuple. Note: these values are determined by the VMM's launch configuration—essentially VM creation flags—rather than derived from guest source code.
  8. Serialize the tuple as canonical JSON, calculate its SHA-256 digest, and compare that digest with the measurement-tool output digest recorded in the provenance manifest.

  Expected SHA-256 digest for the canonical eight-field output from the manifest:
  sha256:88d41f634ae1cb02993e69620739da3dcea2d373e226ae0fbc0b277d63413797

  Related evidence and source:

  • OS image
  • Docker configuration
  • Measured environment
  • Measured Docker Compose file
  • Platform firmware
  • Calibration baseline
  • Calibration boot event log
  • Workload boot event log
  • GCP TDX machine profile

All eight values match?

• Reproduced TDX measurements matchverified
  Technical details

  Recomputes all eight TDX measurements from the OS image, workload configuration, and platform inputs, then compares them with the values shown in Source info.

  provider reproduced all eight declared TDX fields

  Related evidence and source:

  • OS image
  • Docker configuration
  • Measured environment
  • Measured Docker Compose file
  • Platform firmware
  • Calibration baseline
  • Calibration boot event log
  • Workload boot event log
  • GCP TDX machine profile

Does each exact container image connect to the claimed source code and build workflow?

• executor-go — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • executor-go — Docker image metadata
  • Source commit
  • GitHub attestation run

An independent OS rebuild is an offline step for the user. Matching the recorded OS to an approved profile in step 3 does not mean this request rebuilt it.

Reviewing whether the source is safe and appropriate for its capability is a human judgment. This report does not perform that audit.