Repository navigation
Guest Components And Boot Identity
The host hashes the intended NSIS executable and supplies that expected
hash with the non-secret attempt metadata. The VNC-delivered launcher
independently hashes the selected executable and refuses to start it on a
mismatch, read failure, or inability to prevent replacement of the checked
file before execution. The executable is launched from verified read-only
media or a protected staging location with a proven same-file check. Any
separately executed helper must also be verified or embedded in the
verified payload. It starts the matching executable with
Start-Process -Wait -PassThru, captures the returned process's actual
exit code, and reports it over serial. The source commit and binary hash
are separate identifiers, not a claim of reproducible-build attestation. A
launch request, a zero child exit, and independently verified ready state
are three separate facts. A reboot or
launcher failure before an exit report leaves the attempt unknown. The
launcher and NSIS receive only non-secret VM, attempt, and policy
identifiers as arguments; credentials are not embedded in shell commands,
script bodies, process arguments, serial records, or logs. Post-Setup guest
secrets travel only over an authenticated encrypted input stream; VNC
credentials are not passed as process arguments. The actual protected-input
and VNC-control mechanisms require feasibility proof: the current VNC
client and VBoxManage invocation both put the VNC password in process
arguments, and the current console command can print it.
The initial Windows account password is a separate, pre-WinRM case. The existing unattended template has password fields and the builder supplies a password file; protected local unattended media may continue to carry that secret. Protect the host password file, generated answer files and media with verified owner-only custody before use, and never publish them. Prove when Setup no longer needs the media, then detach and clean up its host-side copies without interrupting an active Setup. Preserve interrupted media privately until it is safe to remove. Guest-side copies and their access controls also need verification. File removal on SSD is not a claim of cryptographic erasure.
NSIS owns configuration changes and installs a separate read-only boot
witness after OOBE, not during specialize. The witness checks actual
state on boot and upon an authorized recheck; it never repairs drift,
disables itself after success, or treats a completion marker as proof.
Its sole guest-state write is a boot-evidence UUID in a protected
REG_OPTION_VOLATILE key under an NSIS-owned registry parent. A service
restart in the same boot reuses the value; a full guest restart must
discard it and cause a new UUIDv4 to be created. Microsoft specifies that
RegCreateKeyEx
ignores the volatile option for a key that already exists. The witness
must not assume an existing key is volatile merely because it requested
that option; unverified key provenance or lifetime is unknown, not a
reason to delete it silently. Failure to create or read the key is also
unknown, not a fallback to a timestamp. This evidence-only write is not a
configuration repair. The service identity, required read permissions,
and verification of key lifetime remain feasibility gates; do not silently
elevate it.
The parent stores the non-secret VM UUID, current attempt ID, expected
policy descriptor, and its hash under a restrictive ACL. Before a managed
reboot of a running VM, the host arms the next attempt ID through the
authenticated encrypted channel and confirms that the guest stored it;
failure aborts the reboot. The witness reports that ID after boot. An
authorized recheck on the current boot similarly arms a new attempt and
signals the witness; it does not run NSIS. For the initial attempt, NSIS
establishes this metadata and boot ID after the launcher's Setup and
elevation checks. A standalone recheck produces a readiness-recheck
receipt for current state only; it is not fresh-start or reboot proof. If
a prior boot ID is known and has changed, classify the situation as a
possible guest-only reboot and block continuation pending corroboration.
If a VM is already powered off and no new attempt was armed before it
stopped, its first boot report may contain the last attempt ID and is
diagnostic only. After startup, arm the new ID through authenticated
WinRM, or use an explicitly authorized non-repair VNC recheck launcher if
WinRM is unavailable, then record a fresh boundary and request a witness
recheck. Only that new attempt's record can satisfy readiness. An
initially-off VM with no earlier boot baseline can prove a fresh start
after observed off/on and current readback, but not a full Windows kernel
restart or a prior-to-current reboot comparison. Its receipt uses
fresh-start, not managed-restart or guest-reboot, and cannot satisfy
TEST-061's reboot proof.
Windows Fast Startup
can restore a hibernated kernel after shutdown. Microsoft documents that an
HKLM volatile key is discarded when its hive unloads on a full shutdown,
not simply whenever a VM is observed off. An off/on transition with an
unchanged or unverifiable boot ID therefore cannot satisfy
managed-restart; report the reboot proof as unknown. Do not silently
disable Fast Startup or change the shutdown policy to obtain a pass.
Supported guest behavior and the chosen shutdown path need explicit proof.
An unplanned guest-only reboot cannot be armed in advance. Preserve the last verified boot baseline; any automatic witness output carrying the old attempt ID is diagnostic only. After reconnecting, arm a new attempt through authenticated WinRM or an explicitly authorized non-repair VNC recheck, record a fresh serial boundary, and request a new witness record. Compare the independently obtained boot observations against the retained baseline. If the baseline, new status, or corroboration is unavailable, the outcome remains unknown; do not relabel it as a fresh start or automatically rerun NSIS.
The last verified baseline and any known, unresolved reboot-proof
obligation must survive process restarts under protected host custody.
The client must not replace the baseline or treat pending proof as cleared
because an attempt failed or returned UNKNOWN. A valid resolution may
already have committed before a response was lost; independently recover
that state rather than overwriting it with the older local baseline.
Omitting a baseline or issuing a readiness-recheck or runner-registration
request must not clear the pending obligation. Lost, corrupt, or
unavailable continuity is unknown, not proof that no baseline ever
existed. The storage format,
integrity checks, atomic recovery, and coordination with the UUID lock are
feasibility gates; they must be specified and tested before implementation.
The separately authorized baseline-free fresh-start after observed
off/on never proves an earlier guest-only reboot.
An informational readiness-recheck may establish current readiness
without resolving a separate pending reboot obligation. Its PASS is
not permission to continue a dependent lifecycle or registration phase.
Those phases must re-read continuity under the UUID lock and remain
UNKNOWN while any applicable obligation is pending; they cannot infer
its absence from a recheck receipt, which does not encode pending state.
For such a blocked dependent phase, checks.boot=UNKNOWN and the reason
is REBOOT_PROOF_UNAVAILABLE, even if the current boot ID is readable.
The affected proof-collection or recovery attempt may still run and may
resolve only the obligation it independently proves. The recheck still
requires the same boot ID when a baseline is known.