This page is served by an ordinary tenant of dstack-webhost. Its job is to expose kernel-namespace evidence about itself so a relying party can corroborate — independently — what the substrate claims about which OCI runtime is mediating tenant syscalls inside the CVM.
The substrate is the small daemon that brings up tenant containers. It claims a runtime via /_api/substrate. This page fetches that claim and the tenant's own /proc, then checks the two against each other.
loading…
loading…
Each OCI runtime leaves a different fingerprint inside the tenant. The substrate's effective_runtime claim should match the fingerprint we observe; if it doesn't, something is being misrepresented.
runc (default, no hardening) — uid_map = 0 0 4294967295 (trivial; root inside is root outside), kernel_release matches the host's actual kernel (e.g. 6.9.0-dstack).sysbox-runc (Nestybox; namespace/cap hardening) — uid_map is shifted (e.g. 0 100000 65536; root inside is a non-zero UID on the host), kernel_release still matches the host. The shift is the signature of an active user-namespace remap.runsc (gVisor; userspace kernel) — uid_map is trivial again, but kernel_release is something like 4.4.0 — gVisor's Sentry synthesises a fake kernel for the workload because Sentry is the kernel boundary. The fake kernel string is the signature; trivial uid_map alone wouldn't tell you anything.A malicious substrate could lie in /_api/substrate, but it cannot forge the tenant's own /proc/self/uid_map or what the kernel reports for uname -a.
A multi-tenant TEE makes a strong claim — "your code ran here, others' code can't tamper with yours" — but that claim is only as good as the isolation between co-tenants. The TEE attestation says what code is running; it does not by itself say what's keeping co-tenants from each other's secrets and files. That's an OCI-runtime job.
Two relevant runtimes: sysbox-runc hardens the existing kernel boundary (user-namespace remap, virtualised /proc and /sys, scoped capabilities). gVisor goes further: a userspace kernel mediates syscalls so most kernel CVEs are unreachable. gVisor is stronger, but on Phala dstack TDX CVMs nested KVM isn't exposed, so gVisor would have to ship in the dstack base image (a coordinated change). sysbox-runc is registered as a Docker runtime on stock dstack today, so it's the isolation layer that's deployable now without changing the base image.