Documentation updates.

- Add snapshot management section
- Update snapshot docs to reflect ARM support.

Signed-off-by: Andrei Sandu <[email protected]>

Author: sandreim

docs/snapshotting/snapshot-support.md

@@ -6,6 +6,7 @@
 - [Snapshotting in Firecracker](#snapshotting-in-firecracker)
     - [Supported platforms](#supported-platforms)
     - [Overview](#overview)
+    - [Snapshot files management](#snapshot-files-management)
     - [Performance](#performance)
     - [Known issues and limitations](#known-issues-and-limitations)
 - [Firecracker Snapshotting characteristics](#firecracker-snapshotting-characteristics)
@@ -75,6 +76,27 @@ This has the advantage of very fast snapshot loading times, but comes with the c
 of having to keep the guest memory file around for the entire lifetime of the
 resumed microVM.
 
+### Snapshot files management
+
+The Firecracker snapshot design offers a very simple interface to interact with 
+snapshots but provides no functionality to package or manage them on the host.
+Using snapshots in production is currently not recommended as there are open 
+[Known issues and limitations](#known-issues-and-limitations).
+
+The [threat containment model](../design.md#threat-containment) model states
+that the host, host/API communication and snapshot files are trusted by Firecracker. 
+
+To ensure a secure integration with the snapshot functionality, users need to secure 
+snapshot files by implementing authentication and encryption schemes while managing their 
+lifecycle or moving them across the trust boundary, like for example when provisioning 
+them from a respository to a host over the network.
+
+Firecracker is optimized for fast load/resume and it's designed to do some very basic 
+sanity checks only on the vm state file. It only verifies integrity using a 64 bit CRC 
+value embedded in the vm state file, but this is only as a partial measure to protect 
+against accidental corruption, as the disk files and memory file need to be secured as 
+well.
+
 ### Performance
 
 The Firecracker snapshot create/resume performance depends on the memory size,

docs/snapshotting/versioning.md

@@ -113,9 +113,9 @@ new Firecracker process.
 
 ### CPU model
 
-Firecracker micromVMs can run on Intel/AMD CPU models that support the hardware virtualizations extensions. Snapshots are not compatible across CPU architectures and even across CPU models of the same architecture. They are only compatible if the CPU features exposed to the guest are an invariant when saving and restoring the snapshot. The trivial scenario is creating and restoring snapshots on hosts that have the same CPU model. 
+Firecracker micromVMs snapshot functionality is available for Intel/AMD/ARM64 CPU models that support the hardware virtualizations extensions, more details are available [here](../../README.md#supported-platforms). Snapshots are not compatible across CPU architectures and even across CPU models of the same architecture. They are only compatible if the CPU features exposed to the guest are an invariant when saving and restoring the snapshot. The trivial scenario is creating and restoring snapshots on hosts that have the same CPU model. 
 
-To make snapshots more portable across Intel CPUs Firecracker provides an API to select a CPU template which is only available for Intel - T2 and C3. These templates are mapped as close as possible to AWS T2/C3 instances in terms of CPU features. There are no templates available for AMD. Firecracker CPU templates mask CPUID to restrict the exposed features to a common denominator of multiple CPU models. 
+To make snapshots more portable across Intel CPUs Firecracker provides an API to select a CPU template which is only available for Intel - T2 and C3. Firecracker CPU templates mask CPUID to restrict the exposed features to a common denominator of multiple CPU models. These templates are mapped as close as possible to AWS T2/C3 instances in terms of CPU features. There are no templates available for AMD or ARM64. 
 
 It is important to note that guest workloads can still execute instructions that are being masked by CPUID and restoring and saving of such workloads will lead to undefined result. Firecracker retrieves the state of a discrete list MSRs from KVM, more specificically the MSRs corresponding to the guest exposed features.