Drop the host-side volume placement option and re-attribute the namespace sabotage #23

Merged

vnprc merged 2 commits from agent/microvm-drop-host-volume-option into master

2026-07-30 22:48:08 +01:00

allod-agent commented

2026-07-30 08:41:27 +01:00

Member

Refs allod/strategy#20

Contract 17 no longer claims volume images have two sides to agree

The independent review of allod/nexus#24 found that a host-side volume-placement option is a duplicate source of truth. A credential has a genuine source/destination split — the private source path the launcher installs plaintext from is a different fact from the guest's derived destination — so nexus.microvm.machines.<name>.credentialSources stays. A volume image has no such split: the host path can only live in the guest's microvm.volumes[].image, because that is the string QEMU renders into -drive file= and the same field the root launch helper preflights. A second host-side declaration resolves one of two bad ways once archetypes wires it in milestone 4 — the deployer types the path twice and an assertion keeps them in sync, or archetypes derives the guest value from the option and the assertion compares it against itself.

So the option is gone from nexus, and with it the equality assertion and its mutation fixture. Removing it changed nothing generated: the isolation test's derivation came out byte-identical to the one that had already passed, which is the strongest available evidence that the option fed no artefact. This PR drops the matching clause from contract 17, drops "writable-volume placement" from the nexus scope bullet, and rewrites the persistent-state ownership bullet to say where placement actually enters. Contract 13 already carries the real requirement — the launcher refuses a missing, non-regular or inaccessible declared image before QEMU starts — so nothing is lost.

The milestone-4 consequence is the point of recording it: whoever wires archetypes should not build the duplication in.

The namespace sabotage is attributed differently, because the measurement says so

The cross-VM isolation check required two sabotage fixtures, each reopening the attacks it corresponds to, with removing the launcher namespace reopening the direct-path attacks. The shared-principal half holds exactly as written and reopened every procfs attack. The namespace half did not, and the reason is worth keeping: every source parent the launcher creates is root-only, so a runner without the namespace cannot reach its own credential directory or its own QMP directory either, and QEMU never starts. The namespace is not a hardening layer over a working design — it is what makes a runner's own objects reachable without making a sibling's reachable.

A VM that cannot start cannot be attacked, so the direct-path attribution is made non-destructively instead: the same attack matrix runs from the same principal inside and outside the namespace on the working configuration, and every case records which control denies it. The measured outcome — that removing the namespace stops the VM rather than reopening the attacks — is itself pinned by a sabotage node so a later change cannot quietly turn it into something else.

The plan says a measurement that contradicts it wins, and this is that. The load-bearing warning is preserved verbatim: narrowing the procfs case is still the specific outcome that would close allod/nexus#23 with the boundary still open.

Risk

R0. Plan text only. Both changes describe work that has already landed on an open PR with its checks green, so this narrows the gap between the plan and reality rather than widening it.

Validation

Both statements are backed by artefacts in allod/nexus#24: the byte-identical isolation derivation across the option's removal, and the four probe runs (128 case outcomes) whose families record which control denies each case.

Two contract changes that milestone 3's implementation and its review forced, recorded through the normal change process rather than left as a silent divergence between the plan and the code. The plan converged at review pass 10 and this is not a plan-text review pass: it is the case the plan reserves for itself, where implementation changes a contract or a measurement contradicts one. Refs allod/strategy#20 ## Contract 17 no longer claims volume images have two sides to agree The independent review of allod/nexus#24 found that a host-side volume-placement option is a duplicate source of truth. A credential has a genuine source/destination split — the private source path the launcher installs plaintext from is a different fact from the guest's derived destination — so `nexus.microvm.machines.<name>.credentialSources` stays. A volume image has no such split: the host path can only live in the guest's `microvm.volumes[].image`, because that is the string QEMU renders into `-drive file=` and the same field the root launch helper preflights. A second host-side declaration resolves one of two bad ways once archetypes wires it in milestone 4 — the deployer types the path twice and an assertion keeps them in sync, or archetypes derives the guest value from the option and the assertion compares it against itself. So the option is gone from nexus, and with it the equality assertion and its mutation fixture. Removing it changed nothing generated: the isolation test's derivation came out byte-identical to the one that had already passed, which is the strongest available evidence that the option fed no artefact. This PR drops the matching clause from contract 17, drops "writable-volume placement" from the nexus scope bullet, and rewrites the persistent-state ownership bullet to say where placement actually enters. Contract 13 already carries the real requirement — the launcher refuses a missing, non-regular or inaccessible declared image before QEMU starts — so nothing is lost. The milestone-4 consequence is the point of recording it: whoever wires archetypes should not build the duplication in. ## The namespace sabotage is attributed differently, because the measurement says so The cross-VM isolation check required two sabotage fixtures, each reopening the attacks it corresponds to, with removing the launcher namespace reopening the direct-path attacks. The shared-principal half holds exactly as written and reopened every procfs attack. The namespace half did not, and the reason is worth keeping: every source parent the launcher creates is root-only, so a runner without the namespace cannot reach its own credential directory or its own QMP directory either, and QEMU never starts. The namespace is not a hardening layer over a working design — it is what makes a runner's own objects reachable without making a sibling's reachable. A VM that cannot start cannot be attacked, so the direct-path attribution is made non-destructively instead: the same attack matrix runs from the same principal inside and outside the namespace on the working configuration, and every case records which control denies it. The measured outcome — that removing the namespace stops the VM rather than reopening the attacks — is itself pinned by a sabotage node so a later change cannot quietly turn it into something else. The plan says a measurement that contradicts it wins, and this is that. The load-bearing warning is preserved verbatim: narrowing the procfs case is still the specific outcome that would close allod/nexus#23 with the boundary still open. ## Risk R0. Plan text only. Both changes describe work that has already landed on an open PR with its checks green, so this narrows the gap between the plan and reality rather than widening it. ## Validation Both statements are backed by artefacts in allod/nexus#24: the byte-identical isolation derivation across the option's removal, and the four probe runs (128 case outcomes) whose families record which control denies each case.

allod-agent added 1 commit

2026-07-30 08:41:27 +01:00