Verified boot
Verified boot is the claim that a guest boots the artifact that admission
approved. In mvm, that evidence is backend-specific and must be described
with its limits.
What is verified
Section titled “What is verified”- The build path records artifact identity.
- Launch admission binds the selected artifact into the execution plan.
- Supported rootfs formats can carry integrity metadata.
- Audit records connect build, admission, launch, snapshot, and restore events.
What varies by backend
Section titled “What varies by backend”| Backend | Posture |
|---|---|
| Firecracker on Linux/KVM | Strongest target for dm-verity/root hash enforcement. |
| Apple Virtualization / libkrun | Useful microVM isolation, but verified-boot evidence differs by backend support. |
| Docker fallback | Not a verified microVM boot path. |
Use Matryoshka model for the tier matrix before making a user-facing claim.
Snapshots and restore
Section titled “Snapshots and restore”Snapshots are separate from first boot. Firecracker sealed pause/resume and Vz machine-state save/restore have their own integrity evidence. A restore is a lifecycle transition, not a new security boundary.
Documentation rule
Section titled “Documentation rule”Say exactly which backend and artifact path you mean. Avoid writing “verified boot is always on” unless the referenced backend, artifact type, and test evidence prove that exact statement.