refactor(guest): drop the unread mr-kms launch event - #1007
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR removes the unused mr-kms runtime measurement event emission from the guest launch path, and cleans up related KMS configuration prose and documentation so the codebase reflects what is actually verified/enforced.
Changes:
- Remove
mr-kmsemission and the associated RA-TLS certificate parsing/mutex capture fromdstack-utilguest setup; replace the inline closure with a standalonevalidate_kms_rpc_certfunction. - Update KMS warning/config docs (
kms/src/main.rs,kms/src/config.rs,kms/kms.toml) to drop references tomr-kms. - Remove the
mr-kmsrow from the attestation verification tutorial event list.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| dstack/kms/src/main.rs | Updates warning text when attest_rpc_cert = false to remove mr-kms mention. |
| dstack/kms/src/config.rs | Removes stale description about guests extending mr-kms when KMS RPC cert is unattested. |
| dstack/kms/kms.toml | Updates config comments to match the new behavior/documentation (no mr-kms). |
| dstack/dstack-util/src/system_setup.rs | Drops mr-kms emission and related certificate attestation decoding; introduces validate_kms_rpc_cert. |
| docs/tutorials/attestation-verification.md | Removes the mr-kms expected event entry. |
Suppressed comments (1)
dstack/dstack-util/src/system_setup.rs:1955
- Error message capitalization: per the repo style guide, error messages should start lowercase (CLAUDE.md:149-154).
if usage != "kms:rpc" {
bail!("Invalid server cert usage: {usage}");
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
kvinwang
force-pushed
the
fix/drop-mr-kms
branch
from
August 6, 2026 01:02
2de5c5e to
4fac8a2
Compare
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
kvinwang
force-pushed
the
fix/drop-mr-kms
branch
from
August 6, 2026 03:26
98c3e6f to
c9746b2
Compare
kvinwang
enabled auto-merge
August 6, 2026 03:28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
mr-kmsis a write-only measurement.dstack-utilextends RTMR3 with the KMSCVM's
mr_aggregatedafter everyGetAppKey, and nothing anywhere reads itback. Grepping the whole repo — Rust, Solidity, TypeScript, Python, Go, the four
SDKs, test fixtures, event-log snapshots — finds no lookup by name:
Two emitters and three sentences of prose.
dstack/verifier/never mentions it;the only path that could surface the name is
verification.rs:96, which copiesevent.eventinto an RTMR-mismatch diagnostic and therefore never runs on asuccessful verification.
Three things follow from having no reader:
attestation-verification.md:529describes the payload as "KMS public key hash". It is the KMS's
mr_aggregated. Nobody noticed because nobody consumes it.certificate carries a decodable attestation, and skipped for
attest_rpc_cert = falseor an unsupported quote type. A missingmr-kmscould mean an unattested KMS, an unsupported platform, or an older guest —
indistinguishable.
kms/src/config.rs:66claims "a remote verifier can stilltell"; with no reader and no way to disambiguate, it cannot.
the callback needed an
Arc<Mutex<Option<[u8; 32]>>>cloned into thecert_validatorclosure, adecode_app_infocall, and a bespokeis_unsupported_app_info_quotestring-matching helper for the platforms wherethat decode is not supported — all inside what is otherwise a certificate
check.
The intent was KMS build accountability, and that need is real: the KMS root key
survives KMS upgrades by design (onboarding replicates it), so
key-provider,which records the root CA public key, cannot distinguish two KMS builds sharing
one root. But the enforced answer already exists on-chain in
DstackKms.kmsAllowedAggregatedMrs, checked byisKmsAllowedwhen a KMS bootsand asks for that root key.
mr-kmswas an unenforced echo of it.Fix
Remove the event and everything that existed only to produce it.
request_app_keys_from_kms_urlloses the mutex, the clone, thedecode_app_infocall and the take-and-emit block.
cert_validatorcaptures nothing now, so itbecomes a plain function next to the file's other one,
AppIdValidator:Dropping
decode_app_infofrom the validator removes no check.ra-rpc/src/client.rs:157runsverify_with_ra_pubkey— report-data binding tothe certificate SubjectPublicKeyInfo, quote signature, collateral — before
calling the validator.
decode_app_infoonly parsed identity out of the KMS'sevent log to reach
mr_aggregated, and withmr-kmsgone nothing consumes thatlog. The KMS identity the guest actually enforces is its CA public key, pinned by
verify_key_provider_idagainstapp_compose.key_provider_id.The stale prose in
kms/src/config.rs,kms/src/main.rs,kms/kms.tomland theincorrect docs row go with it.
Alternative considered
Finishing the feature instead: have
dstack-verifiersurfacemr-kmsinVerificationResponse.details, cross-check it againstkmsAllowedAggregatedMrs, and emit it unconditionally so absence stops beingambiguous. Rejected for now — it is a new verification surface with an on-chain
dependency, and shipping it should be a deliberate design change rather than a
rescue of an event that has had no reader since #135. Removing it first keeps the
launch log honest about what is actually checked; the accountability question can
be reopened on its own terms.
Compatibility
No allowlisted measurement changes.
boot-mr-doneis emitted atsystem_setup.rs:2641, beforerequest_app_keys()at:2717, somr-kmsalways landed after the boot-time snapshot. The on-chain KMS and app policies
read that truncated snapshot (
replay_runtime_events(.., Some("boot-mr-done"))),which never contained it. Registered
mrAggregatedanddeviceIdentries areuntouched.
Only the runtime RTMR3 of newly built guest images changes, and no authorization
path reads it. Event-log replay is name-agnostic, so an existing CVM whose log
contains
mr-kmsstill replays to its quoted RTMR3 and verifies unchanged — noverifier-side change is needed for either generation.
Verification
rg -n 'mr[-_]kms'over the worktree returns onlyCHANGELOG.mdhistory.cargo clippy -p dstack-util -p dstack-kms --all-targets: no new warnings(the two remaining ones are pre-existing, in
amd_attest.rsandonboard_service.rs).cargo test -p dstack-util -p dstack-kms: 102 passed, 0 failed.ra-rpc/src/client.rs:145-165verifies the attestation and only then invokesthe validator.
boot-mr-doneatsystem_setup.rs:2641precedesrequest_app_keys()at:2717.