Repository navigation
OpenVMM prerequisite: verify and receipt opened host attachments #548
Description
Parent: #535. Parallel OpenVMM attachment prerequisite for object-pinned cold and platform-restore launches; required for #541 and #543 acceptance. #538 owns the typed host grant/authorization boundary; implement/review this VMM mechanism in nanvix/openvmm and pin its revision in NVX. It is independent of filesystem-slot omission and of #540's dormant-to-aggregate topology change.
Why
The existing cold --microvm-sandbox-block, --mount and --mount-child inputs name paths and modes, but do not prove which object OpenVMM actually opened after host authorization. Existing aggregate file children intentionally follow a pathname replacement even through an already-held guest node. That is valid for an explicit live/follow-name grant, not an object-pinned grant or an immutable image. A pre-launch path check and an unverified identity label are insufficient; do not make a forged or replaced object look like a successful admission.
Contract
- Provide a versioned VMM handoff for caller-approved object-pinned read-only image/block media and mapped filesystem roots or file children: transfer a verified opened handle or pass an expected platform file identity for VMM to compare with its actual opened handle (device/inode or volume/file ID). Validate kind, access mode, size/sector geometry where applicable, and the caller's protected-root constraints before admitting the attachment. Return a receipt recording the stable device/child role, kind/mode and observed opened identity; bind it to the authenticated activation/Ready identity. Do not hash large images or snapshot RAM per start/exec.
- For a pinned file child, a pathname replacement after attachment must continue to serve the originally approved object or fail closed, including an already-held guest node and a new lookup/open. For a pinned directory root, the selected root identity remains the approved root; allowed changes within it follow the declared subtree policy. Never silently degrade a pinned grant to live-name behavior. Preserve existing follow-name replacement semantics for callers that explicitly authorize a live-path grant.
- Fail a changed image, root, file kind, unauthorized path, receipt mismatch or opened-handle race before guest Ready; a failed platform restore tears down the verified VM instead of silently cold-booting. Preserve the exact-match behavior of old/workload snapshots and the VMM policy boundary independently of guest cooperation.
Acceptance
- Race tests swap an authorized block image, mapped root and file child between host validation and the VMM open on cold and restored launches. Pinned objects either match the actual opened handle/receipt or fail; no substituted object reaches Ready. A safe idempotent bind retry queries the same observed image identity.
- After Ready, replace a pinned file child's pathname and test both an existing held guest node and a new lookup: neither sees the replacement. Inject failure to retain/detect the original and require fail-closed teardown. A separate live-path test retains existing replacement behavior.
- Host-plan/receipt tests exercise
--mount, aggregate RO/RW/file children, protected roots, read-only image media and denied paths across supported host platforms; source-bound end-to-end cold and restore cases pin the reviewed VMM change. No unnecessary object-hash appears on the hot path. - Keep this grant/receipt work separate from the single-image-slot prior art guest: add Ubuntu userland support #116/Adopt bind-once microVM image slots #406; nvx-rs: prove cross-image platform restore with pre-ready activation RPC #542's sole
image0bind/query uses the same opened-object invariant without inheriting four-slot topology.
Activity
esaurez commentedon Oct 20, 2026
The cold block part of this issue moves to #622 (A4): the host checks the image file and hands that checked file to the VMM, with no VMM change. Opened-object receipts for restore stay here until the platform-clone meta issue is filed.