Home

Workload 0xac29ee8d193394744ce238d0c68f9a30a4dd52707564c3d87f954163a3c2f325

Overall status: verified.

Download provenance bundle (.tar)

Source info

TDX measurements

MRTD0xb24d3b24e9e3c16012376b52362ca09856c4adecb709d5fac33addf1c47e193da075b125b6c364115771390a5461e217
RTMR00x90550e56509b94f99f4670a563e0dd0a2fa79b6d7b97fd52d051069d1b33d270b1858120034a43dac4f8daf509f2aeda
RTMR10x07e6f51aa763abfe75c3ddfbf4f425fe3f0ceff66d807a75e049303dce9addf68e7218729bd419638af63a370f65878c
RTMR20xf1c82667a354194467cd8419efd14a714560dd9b85b4c13b25c11e44bf4e126248c2255fad58c303fb0ca2921765d53a
RTMR30x00b1aeaf809e3b847256f102de14fc1803a7da87bceb09747febe93a644be551dd265fec6f79c8f5260f5ba796f9ece6
MRCONFIGID0x019dbf79e75ef4218f8355a31c5af7198ebe7fe4268230b18d3909604fb699592b000000000000000000000000000000
XFAM0xe702060000000000
TD attributes0x0000001000000000

Measured workload inputs

These exact files are inputs to the TDX measurement calculation for this workload.

Docker container images and source

dstack OS release source

Dstack-TEE/meta-dstack@e3655d1390feee3736476f4bda35c4354b4a12fc · dstack reproduce script referenced by the platform profile

Platform profile

This workload records the opaque ID of the authority-accepted platform profile required to verify it.

pp_b06ed351-1955-476e-885a-883c5d9086d1
Download platform-profile bundle (.tar)

Detailed verification checks

Follow the links from the workload ID to its measurements, images, and source code. Expand a check to see what it establishes and inspect the supporting evidence.

Provenance record

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. A verifier uses these references to obtain each available artifact, confirm that its bytes match the recorded digest, and supply the verified artifact to the corresponding verification check.

Download provenance manifest (JSON)

1. Start with an on-chain workload ID

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

Workload ID being checked: 0xac29ee8d193394744ce238d0c68f9a30a4dd52707564c3d87f954163a3c2f325

2. Look up the TDX measurements

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

3. Reproduce the OS + Docker → TDX measurements

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 Phala/dstack, the provider profile is accepted in a separate offline phase, where the service validates the published dstack release bundle, confirms its size and os_image_hash, and replays known measurement vectors with the pinned dstack-mr tool. The service does not rebuild the recorded meta-dstack commit; that separate source-to-release check can be repeated with Phala’s published reproduction script.

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 Phala/dstack, the measured configuration is the exact app_compose document, which contains the embedded Docker Compose file and other application policy. Here, we validate the connection between the Docker images and app_compose. The app_compose hash can then be connected to MRCONFIGID and to the compose-hash event replayed into RTMR3. The service publishes app_compose and the captured VM configuration so you can inspect the exact inputs or repeat the calculation.

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 Phala/dstack, the published OS release supplies the exact boot artifacts used to reproduce MRTD, RTMR1, and RTMR2: the OVMF firmware, Linux kernel, initrd, root filesystem hash, and kernel command line. RTMR0 also depends on the VM launch configuration—CPU, memory, and devices—which OVMF records in its boot events. The captured event log preserves the OVMF event digests used to reproduce RTMR0 in the complete-tuple procedure below.

published dstack OVMF firmware                    → MRTD
VM launch configuration + captured OVMF events    → RTMR0
published Linux kernel image                       → RTMR1
kernel command line + initrd + rootfs hash         → RTMR2
offline-approved VMM launch-field profile           → MRCONFIGID format, XFAM, TDATTRIBUTES

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 Phala/dstack, the pinned dstack-mr binary calculates MRTD, RTMR1, and RTMR2 from the verified dstack release and VM settings. The verifier replays the captured IMR0 event digests for RTMR0, replays the dstack runtime-event chain for RTMR3, and derives MRCONFIGID, XFAM, and TDATTRIBUTES from the checked configuration.

All eight values match?

4. Verify each GitHub attestation

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

5. (Optional) Rebuild the OS image

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.

6. (Optional) Source audit and capability review

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

All verification files

This appendix lists every verification input. Retained files and directly addressable external references are linked.

InputLocator
dstack reproduce scripthttps://github.com/Dstack-TEE/meta-dstack/releases/download/v0.5.9/reproduce.sh
dstack release bundlehttps://github.com/Dstack-TEE/meta-dstack/releases/download/v0.5.9/dstack-nvidia-0.5.9.tar.gz
Phala app configurationcdi-phala-app-compose.json
dstack-mr build instructionsevidence/measurement-tool-build-definition
dstack reconstruction configurationcdi-phala-dstack-reconstruction-config.json
dstack event logcdi-phala-event-log.json
Phala TDX machine profilecdi-phala-machine-profile.json
attested-alpine — Docker image metadatadocker.io/ritualnetwork/attested-alpine@sha256:2296aa2ab950dd79c04a077af8b8d7de1c86f3c2402e6415e753be63b75b6dab
attested-bifrost — Docker image metadatadocker.io/ritualnetwork/attested-bifrost@sha256:99687dd5b49bed19aff7b37f0ec22b0e145da9cb17e0096b415b2b3d41e3893f
attested-dynamo-sglang — Docker image metadatadocker.io/ritualnetwork/attested-dynamo-sglang@sha256:f769e1278140b2a396cb1248be0802d4b2360fef4f3ca0b6cf4acf2edcf132ef
attested-etcd — Docker image metadatadocker.io/ritualnetwork/attested-etcd@sha256:4c15df3a62f8ffb25007194b09ab89731bd8ae4cc98a5cccb76bceff8d257232
attested-nats — Docker image metadatadocker.io/ritualnetwork/attested-nats@sha256:0275c31c7b0100817abd03a10dc519697f0fdc710de8fa8c5c7f7ad41607e542
attested-redis — Docker image metadatadocker.io/ritualnetwork/attested-redis@sha256:ab7cc60b5a997c5df4241a7de2508af1a05d01ee2a7506565928af44263d8c56
attested-sglang-diffusion — Docker image metadatadocker.io/ritualnetwork/attested-sglang-diffusion@sha256:4a4e3223abcb7f7323868be64ac00b7091ac87cbb052622c40e6c341419e4cff
attested-sglang — Docker image metadatadocker.io/ritualnetwork/attested-sglang@sha256:636477429594b690d83a0bb086b04c52086390c63be78141918e356b04ae904e
rai-simple — Docker image metadatadocker.io/ritualnetwork/rai-simple@sha256:d0269af97a4d722a48647d723e7aff8a5bddcd1977b64347c14d162c35cfc7f0
ritual-moai-gpu — Docker image metadatadocker.io/ritualnetwork/ritual-moai-gpu@sha256:2f6e0751cf2383cd67cc1510adcd70699bba402d7d6a8ee285e08f438ace2245
ritual-vllm-proxy-go — Docker image metadatadocker.io/ritualnetwork/ritual-vllm-proxy-go:cf17d76-93d86b2-amd64@sha256:3b7b49baba9bad656403f9636ff5eecc7c6f8b9c612639c46ea9433c3afee83f
dstack verifier image metadatadocker.io/dstacktee/dstack-verifier@sha256:06a20b777e59196c7f54b0cd02ffe567df6d05ae39a0b2fea9cb0642fb23c1fd

Phala verification references

This record measures the published Phala OS release with dstack-mr. Rebuilding that OS from source is an optional offline step you can run with Phala's reproduce.sh; this site does not perform it.