Home

Workload 0x93f99d05ef2a9abae0fd84653471bddfd32a460c98be42326cdc665f9d76b156

Overall status: incomplete.

Download provenance bundle (.tar)

Source info

TDX measurements

MRTD0xb24d3b24e9e3c16012376b52362ca09856c4adecb709d5fac33addf1c47e193da075b125b6c364115771390a5461e217
RTMR00x90550e56509b94f99f4670a563e0dd0a2fa79b6d7b97fd52d051069d1b33d270b1858120034a43dac4f8daf509f2aeda
RTMR10x07e6f51aa763abfe75c3ddfbf4f425fe3f0ceff66d807a75e049303dce9addf68e7218729bd419638af63a370f65878c
RTMR20xf1c82667a354194467cd8419efd14a714560dd9b85b4c13b25c11e44bf4e126248c2255fad58c303fb0ca2921765d53a
RTMR30x065765bd373bb53fdcaa09df3f14b861b06df3d3504b85911a5074f7e28c06b52e86d59916111c14cbdb8c1334760464
MRCONFIGID0x011ddda8f6c2219063efe067c7ea4839c0e0b8a3bf2c0a85d6eed2f3f6a838cfd1000000000000000000000000000000
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: 0x93f99d05ef2a9abae0fd84653471bddfd32a460c98be42326cdc665f9d76b156

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
alpine — Docker image metadatadocker.io/library/alpine:3@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
nats — Docker image metadatadocker.io/library/nats:2.10-alpine@sha256:b83efabe3e7def1e0a4a31ec6e078999bb17c80363f881df35edc70fcb6bb927
redis — Docker image metadatadocker.io/library/redis:7.4-alpine@sha256:ff02b58f971e7d7d156a1267e283fcbbeee91773b6aa36c49dac28ecfe28eadf
sglang — Docker image metadatadocker.io/lmsysorg/sglang:v0.5.17@sha256:3be8803490a8b899a44f7ab2e22d8f6a1fb877cab52faeb400769a1555317db4
bifrost — Docker image metadatadocker.io/maximhq/bifrost:v1.5.7-amd64@sha256:410de09d5b96b15bda204dc73ac4a7d1712d598d0b9e67a8e8917b964968ab79
dynamo-sglang — Docker image metadatadocker.io/ritualnetwork/dynamo-sglang:v0.5.17-dsv4@sha256:9cc856356107915be6028fb693c600012d570a6d736d21c622aff0a89995089e
rai-simple — Docker image metadatadocker.io/ritualnetwork/rai-simple:pt1-release-01-8bd2899@sha256:de96e7daac3e0b07e608d189fd51442d9961798032cf03c7bbbe4a3f7bd5c643
ritual-moai-gpu — Docker image metadatadocker.io/ritualnetwork/ritual-moai-gpu:8102c66-amd64@sha256:63113fdf2bf457b84e53e325611e65f488783cd2e39f24ff65d1bf1e5c308543
ritual-vllm-proxy-go — Docker image metadatadocker.io/ritualnetwork/ritual-vllm-proxy-go:cf17d76-0e65f02-amd64@sha256:d9e9bdd3adde92f5b2217981782bb8201a5be4bb6057a4fb044d32d1e0f92dbd
image_10 — Docker image metadatadocker.io/ritualnetwork/sglang:v0.5.17-diffusion-accelerate1.14.0-tdx1@sha256:9fbe8c2f36ed46b3ec042b81de80d1eba344517decae86d781f20dc4b88cdfd5
etcd — Docker image metadataquay.io/coreos/etcd:v3.5.16@sha256:d967d98a12dc220a1a290794711dba7eba04b8ce465e12b02383d1bfbb33e159
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.