doc: update VMGenID docs to mention ARM support

Mention that Linux support VMGenID for systems with DeviceTree support
since version 6.10. Also, mention that we only support up to Linux 6.1,
so users that want to make use of VMGenID on Linux 6.1 they need to
backport DeviceTree support from 6.10.

Signed-off-by: Babis Chalios <[email protected]>

Author: bchalios

docs/snapshotting/random-for-clones.md

@@ -43,8 +43,6 @@ and there’s also an input pool which gathers entropy from various sources
 available on the system, and is used to feed into or seed the other two
 components. A very detailed description is available [here][3].
 
-### Linux kernels from 4.8 until 5.17 (included)
-
 The details of this newer implementation are used to make the recommendations
 present in the document. There are in-kernel interfaces used to obtain random
 numbers as well, but they are similar to using `/dev/urandom` (or `getrandom`
@@ -103,15 +101,17 @@ not increase the current entropy estimation. There is also an `ioctl` interface
 which, given the appropriate privileges, can be used to add data to the input
 entropy pool while also increasing the count, or completely empty all pools.
 
-### Linux kernels from 5.18 onwards
-
-Since version 5.18, Linux has support for the
-[Virtual Machine Generation Identifier](https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-machine-generation-identifier).
-The purpose of VMGenID is to notify the guest about time shift events, such as
-resuming from a snapshot. The device exposes a 16-byte cryptographically random
-identifier in guest memory. Firecracker implements VMGenID. When resuming a
-microVM from a snapshot Firecracker writes a new identifier and injects a
-notification to the guest. Linux,
+### Linux kernels with VMGenID support
+
+Linux has support for the
+[Virtual Machine Generation Identifier](https://learn.microsoft.com/en-us/windows/win32/hyperv_v2/virtual-machine-generation-identifier)
+since 5.18 for ACPI systems. Since 6.10, Linux added support also for systems
+that use DeviceTree instead of ACPI. The purpose of VMGenID is to notify the
+guest about time shift events, such as resuming from a snapshot. The device
+exposes a 16-byte cryptographically random identifier in guest memory.
+Firecracker implements VMGenID. When resuming a microVM from a snapshot
+Firecracker writes a new identifier and injects a notification to the guest.
+Linux,
 [uses this value](https://elixir.bootlin.com/linux/v5.18.19/source/drivers/virt/vmgenid.c#L77)
 [as new randomness for its CSPRNG](https://elixir.bootlin.com/linux/v5.18.19/source/drivers/char/random.c#L908).
 Quoting the random.c implementation of the kernel:
@@ -133,9 +133,15 @@ to emit a uevent to user space when it handles the notification. User space can
 poll this uevent to know when it is safe to use `getrandom()`, et al. avoiding
 the race condition.
 
-Please note that, Firecracker will always enable VMGenID. In kernels earlier
-than 5.18, where there is no VMGenID driver, the device will not have any effect
-in the guest.
+Firecracker supports VMGenID on ARM systems using the DeviceTree binding that
+was added for the device in Linux 6.10. However, the latest Linux kernel that
+Firecracker supports is 6.1. As a result, in order to use VMGenID on ARM
+systems, users need to use a 6.1 kernel with the DeviceTree binding support
+backported from 6.10. We provide a set of patches that apply cleanly on mainline
+Linux 6.1 [here](../../resources/patches/vmgenid_dt).
+
+Please note that, Firecracker will always enable VMGenID. In kernels where there
+is no VMGenID driver, the device will not have any effect in the guest.
 
 ### User space considerations
 

docs/snapshotting/snapshot-support.md

@@ -584,28 +584,25 @@ we also consider microVM A insecure if it resumes execution.
 (VMGenID) is a virtual device that allows VM guests to detect when they have
 resumed from a snapshot. It works by exposing a cryptographically random
 16-bytes identifier to the guest. The VMM ensures that the value of the
-indentifier changes every time the VM a time shift happens in the lifecycle of
+identifier changes every time the VM a time shift happens in the lifecycle of
 the VM, e.g. when it resumes from a snapshot.
 
-Linux supports VMGenID since version 5.18. When Linux detects a change in the
-identifier, it uses its value to reseed its internal PRNG. Moreover,
-[since version 6.8](https://lkml.org/lkml/2023/5/31/414) Linux VMGenID driver
-also emits to userspace a uevent. User space processes can monitor this uevent
-for detecting snapshot resume events.
+Linux supports VMGenID since version 5.18 for systems with ACPI support. Linux
+6.10 added support also for systems that use DeviceTree instead of ACPI. When
+Linux detects a change in the identifier, it uses its value to reseed its
+internal PRNG.
 
-Firecracker supports VMGenID device on x86 platforms. Firecracker will always
-enable the device. During snapshot resume, Firecracker will update the 16-byte
-generation ID and inject a notification in the guest before resuming its vCPUs.
+Firecracker supports VMGenID device both on x86 and Aarch64 platforms.
+Firecracker will always enable the device. During snapshot resume, Firecracker
+will update the 16-byte generation ID and inject a notification in the guest
+before resuming its vCPUs.
 
 As a result, guests that run Linux versions >= 5.18 will re-seed their in-kernel
 PRNG upon snapshot resume. User space applications can rely on the guest kernel
 for randomness. State other than the guest kernel entropy pool, such as unique
 identifiers, cached random numbers, cryptographic tokens, etc **will** still be
 replicated across multiple microVMs resumed from the same snapshot. Users need
 to implement mechanisms for ensuring de-duplication of such state, where needed.
-On guests that run Linux versions >= 6.8, users can make use of the uevent that
-VMGenID driver emits upon resuming from a snapshot, to be notified about
-snapshot resume events.
 
 ## Vsock device limitation