Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

nvx-rs: clone plans refuse the templates of adapters whose guest speaks its own control contract

Open
  • Is something wrong?
#1,010 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
linux, rust
Domain
api, backend

Research direction

Start with check_template in nvx-rs/src/host/template/clone.rs, then trace how CloneControl and the launch identity are declared and passed into clone plans. Compare those paths with create_template in nvx-rs/src/host/template/store/capture.rs and reattach_clone in nvx-rs/src/host/template/clone/reattach.rs. Done means adapter-owned control contracts can clone and reattach successfully while NVX's own control contract checks remain intact, with affected template API users and tests accounted for.

Written by the indexing model from the issue text.

Description

Summary

check_template (nvx-rs/src/host/template/clone.rs) refuses every template whose key's runtime identity has a control_contract other than this build's contract::CONTROL_CONTRACT_REVISION. An adapter that boots its own guest, and drives a clone's activation through its own CloneControl, records its guest's control protocol in the runtime identity's control_contract, as it does for its cold boots. NVX then captures that adapter's templates, since capture checks no contract, but refuses every clone of them:

the template's generation N speaks other contracts than this build, which restores none of its clones (stage plan, evidence incompatible-host, outcome host)

Where

At dev (b8b82a60):

  • The check: check_template in nvx-rs/src/host/template/clone.rs (lines 738–760; the control_contract comparison is line 749), added in #888.
  • Capture: create_template (nvx-rs/src/host/template/store/capture.rs, line 406) checks no contract, so the mismatch shows only at the first clone, as a fallback on every start.
  • Launch and reattach: a clone's launch requires the template's runtime identity (Evidence::RuntimeMismatch), and reattach_clone (nvx-rs/src/host/template/clone/reattach.rs, line 163) ends a clone's VMM that runs under another identity. So an adapter can't keep its own contract for clones alone.

The workaround available today

Run templates and clones under a second runtime identity: the adapter's own, with CONTROL_CONTRACT_REVISION in place of its guest's control contract. Cold boots keep the adapter's identity. The adapter's readiness check still enforces its guest's protocol at each activation and reattach, and the identity's digests still pin the guest. But the template and clone identities then record a contract that the guest speaks only through the adapter's own framing: a label that NVX requires and doesn't verify.

Proposal

One of:

  1. Compare with the control that the caller drives. Let the CloneControl implementation, or the clone request, declare the control contract it speaks. check_template then compares the template's control_contract with that, instead of NVX's own revision. NVX's own control declares CONTROL_CONTRACT_REVISION, so its behavior doesn't change.
  2. Compare with the launch identity. The launch already requires the template's runtime identity. check_template could compare the template's runtime with the identity that the caller launches under, and keep the fixed revisions only for NVX's own control.

Either way:

  • The boot contract and control session checks can stay as they are, unless an adapter needs the same for them.
  • create_template could refuse what no clone can use, with the same rule. A template whose contracts no clone plan accepts would then fail at capture, not at every clone.

Downstream

Users of the template API that adopted the workaround above should be checked when this changes. They would move to the new declaration, and their templates would be captured again once, since the key changes.

Related: #833, #847.

Dominant language
Rust
Stars
758
Forks
48
Avg merge
18h 27m
Merged PRs (30d)
446

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/nvx

All issues in microsoft/nvx

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.