Qualify SEV-SNP host-blind mailbox custody and boot latency #5259

Outcome

Choose and qualify one host-blind mailbox reporting profile whose measured sender/recipient cannot have plaintext read by an ordinary host/hypervisor, MVMD, another workload, or an unauthorized user, while measuring its actual ready-to-dispatch latency. This is the concrete evidence gate for the product direction in #4622 and the accepted custody contract #4185; do not relabel ordinary KVM/HVF, TPM2, encrypted disk, or host-sealed guest plaintext as host-blind. #4629 and #4630 retain ownership of the canonical local mailbox service and durable store; #5255 remains the deferred VM-to-VM consumer.

First platform candidate and selection rule

Evaluate AMD SEV-SNP on a dedicated Linux x86_64 KVM host, with Cloud Hypervisor's KVM + IGVM/SEV-SNP path as the first confidential-workload backend candidate. Its upstream SNP configuration documents SNP KVM/IGVM and limitations; vsock is available. This is vendor capability evidence, not MVM integration or a measured security witness. Compare the existing MVM QEMU adapter as a lower-integration-cost spike: QEMU SNP is documented, but current MVM QEMU launch has no SNP/measurement binding and its security profile lacks verified boot. Choose between adapters on actual attestation, image/device compatibility, confinement and p50/p95/p99 ready-to-dispatch evidence, not advertised VMM boot times. Do not nest ordinary MVM guests inside a cloud Confidential VM and infer inner guest protection.

Contract to demonstrate

• Every qualifying production launch is bound to a signed plan, fresh boot/epoch, explicit confidentiality profile, exact workload/runtime measurements, a guest-created ephemeral channel key, and an external verifier nonce. Verify vendor chain, debug-disabled policy, TCB/security version, revocation and signed allowed measurements outside the execution host; a missing or stale proof refuses release and dispatch.
• An authority outside the malicious host's control releases scoped encryption/signing material only into a verified confidential endpoint. The sender encrypts and signs canonical mvm-contract values before they leave that boundary. Hostd/MVMD handle only bounded ciphertext/metadata; no plaintext console, stdout/stderr, audit, crash dump, host tool, or egress endpoint leaks. Explicit result/error messages remain distinct from diagnostic streams.
• A warm, separately measured destination mailbox authority, or equivalently reviewed external recipient service, can issue a destination-signed accepted_durable receipt after canonical encrypted journal/dedup admission, even if a successor workload is offline. An ordinary host signer may report host observations but cannot impersonate the guest, decrypt reports, or mint that receipt. Accepted ciphertext and dedup state survive source teardown and process restart while local storage/keys remain available. A malicious host can deny service/destroy storage; detect replay/rollback via independent freshness/lineage anchor and fail closed, not claim availability against destruction.
• No per-workload mailbox helper or disk namespace creation on the boot critical path. Prewarm VMM image/material and independent verifier transport, but do not cache another boot's attestation or key release. Measure from launch request through ready-to-dispatch after fresh attestation and key release plus separate first-report durable acceptance; report p50/p95/p99, failures, configuration, cold/warm cases and comparison with ordinary supported launch. Do not promise a boot SLO before a baseline and a qualified witness.

Current-source blockers

At mvm@63e751d4, the plan enum names SevSnp/Tdx but says the providers are not implemented (types); the runtime provider has TPM2 only (provider). Existing assurance_attestation is a verification interface, not a native SNP quote verifier or key releaser (seam). The accepted custody contract requires external attestation-bound release and protection of outputs/diagnostics. No current MVM backend has a qualified confidential-guest boot, and the current mailbox host-seals guest plaintext with host-derived keys; #4629 and #4630 are open. A code-only mock test cannot promote these claims.

Acceptance evidence (all required before claiming production host-blind readiness)

• Source-pinned selection review compares MVM QEMU SNP versus Cloud Hypervisor SNP on real guest image/device, attestation path, recipient authority and measured launch, with fail-closed unsupported-backend policy. Record a preferred backend and fallback only after the spike.
• On qualified SNP hardware, prove fresh boot-bound quote, guest-channel-key binding, external trust-root/measurement verification and recipient-bound key release; stale quote, wrong image/plan/tenant/epoch, wrong key, debug-enabled or revoked TCB, missing KMS/verifier all refuse before workload dispatch.
• Guest-authored typed result/error traverses the canonical MVM envelope without host plaintext; an independently authorized destination signs durable acceptance after ciphertext journal commit, then an authorized reader opens/ACKs. Test offline recipient, crash, source teardown, lost receipt/ACK, replay, expiry, quota/full, key loss, journal tamper and rollback.
• Demonstrate no plaintext/key leakage through vsock host buffer, console, stdout/stderr, traces, API, audit, support bundle, snapshot, swap, device/egress path or MVMD; unsupported protected I/O and snapshot/migration operations refuse. Document what metadata remains visible and what attacks (DoS, host destruction, side channels) remain out of claim.
• Reproduce signed configuration and p50/p95/p99 cold and warm ready-to-dispatch timings against ordinary MVM plus first durable-report acceptance; quantify the attestation/release contribution and specify a product boot budget for review, with no security bypass for latency.
• Reviewed ADR-057/key-custody amendment, platform matrix, operational recovery/key-rotation and release evidence precede enabling the profile or calling it production-ready. Add dedicated bounded mailbox vsock service and call/cast API #4629/Persist encrypted mailbox journals, snapshots, and effect receipts #4630/plan 74 W1.4b.3b.3 — Firecracker wiring for the runtime overlay (ADR-051) #254 acceptance remains independent.

Execution boundary

First do source-pinned/no-cost compatibility and mock-protocol design. Native SNP execution and boot timing require a qualified hardware host and externally controlled verifier/key-release authority; the existing macOS-hosted builder VM and ordinary virtual KVM tests do not prove SNP. Do not use a billable host, transfer a checkout to one, provision keys, or publish an image without the operator's explicit authorization for that exact action. Run any Nix/Linux/Firecracker work only inside the project's builder-VM boundary as the repository requires; hardware-only evidence needs a separately approved compatible test environment. Keep all boxes unchecked until executed evidence exists; this issue must remain open otherwise.