Skip to content

Boundaries And Inputs

Jump to bottom
sergio velderrain edited this page Nov 9, 2026 · 1 revision

Boundaries And Inputs

  • Every action after creation uses the verified VirtualBox UUID, not a name alone. For an existing VM, the caller supplies the expected UUID. For a new VM, the host captures the creation result and independently verifies the registered UUID before continuing.
  • allow_hard_poweroff is a boolean, false by default and explicitly supplied per run. authorize_bootstrap_reapply is a separate boolean, false by default, for each post-initial repair attempt. Initial create-vm authorizes its first attempt, not later automatic retries.
  • The host creates a new UUIDv4 attempt ID and verifies VM state before mutation. Snapshotting or unknown state blocks mutation even when a destructive fallback was authorized. The existing graceful and ACPI budgets remain 300 and 120 seconds; longer retries are not the remedy.
  • An exclusive host lock keyed by the verified UUID serializes all ProjectBuddy mutations of that VM, including attempts invoked under different names. For initial creation, serialize by the requested name until the newly created UUID is verified and its lock acquired. An unsafe or unavailable lock fails closed. The lock is held for the whole operation, including evidence finalization, and must be shared by all participating engine processes on the host. It does not govern third-party VirtualBox clients. UUID and state are checked immediately before each mutation, but that recheck alone cannot close a concurrent third-party snapshot race; a verifiable interlock or exclusive-control mechanism is a feasibility gate for live mutation.
  • Before starting a powered-off VM, the host prepares a fresh serial file in an owner-only directory and configures VirtualBox UART1/COM1 to write to it. A port conflict, unsafe path, permission failure, or inability to verify the actual attachment is a failure; an existing unrelated UART1 is never overwritten. For an in-guest reboot while the VM remains running, the same serial file remains in use and the host records a fresh byte boundary before the reboot. For a new host power-on, prepare a new protected file while powered off. If a running VM has no verifiable COM1/file attachment, report unknown rather than changing live hardware or inventing a serial result.
  • VNC may deliver the first launcher, but a screenshot, UI input, log marker, or HTTP response is not a success signal. Before starting NSIS, the launcher checks an elevated interactive Windows session, an Explorer process in that session, SystemSetupInProgress=0, OOBEInProgress=0, and ImageState=IMAGE_STATE_COMPLETE; missing or contradictory evidence is unknown and prevents NSIS configuration. These predicates require validation on the actual Windows image. VNC must be authenticated and bound to host loopback before it accepts connections, with the effective binding independently checked; inability to enforce that order fails closed. No specialize-pass or RunOnce injection is introduced.
  • The host forwards the selected guest's TCP 5985 to 127.0.0.1 on the configured host port. The client uses NTLM with message encryption required, and the guest rejects unencrypted WSMan and disables Basic authentication. There is no silent protocol downgrade. This does not claim TLS certificate-based peer authentication: the host, VirtualBox, and guest are trusted, and identity correlation is not remote attestation. The host independently verifies that the forward belongs to the selected VM and adapter.
  • The authorized remote identity must already have the necessary privileges. The installer never changes network-profile categories, LocalAccountTokenFilterPolicy, or the startup/running state of wuauserv, UsoSvc, or InstallService.

Clone this wiki locally