Firecracker Entropy for VM Clones

Summary

This document provides a high level perspective on the implications of restoring multiple VM clones from a single snapshot. We start with an overview of the Linux random number generation (RNG) facilities, then go through the potential issues we’ve identified related to cloning state, and finally conclude with a series of recommendations. It’s worth stressing that we aim to prevent stale state being a problem only for the kernel interfaces. Some userspace applications or libraries keep their own equivalent of entropy pools and suffer from the same potential issues after being cloned. There is no generic solution under the current programming model, and all we can do is recommend against their use in pre-snapshot logic. The Linux kernel exposes three main RNG interfaces to userspace: the /dev/random and /dev/urandom special devices, and the getrandom syscall, which are described in the random(7) man page. Moreover, Firecracker supports the virtio-rng device which can provide additional entropy to guest VMs. It draws its random bytes from the aws-lc-rs crate which wraps the AWS-LC cryptographic library. Traditionally, /dev/random has been considered a source of “true” randomness, with the downside that reads block when the pool of entropy gets depleted. On the other hand, /dev/urandom doesn’t block, which lead people believe that it provides lower quality results. It turns out the distinction in output quality is actually very hard to make. According to this article, for kernel versions prior to 4.8, both devices draw their output from the same pool, with the exception that /dev/random will block when the system estimates the entropy count has decreased below a certain threshold. The /dev/urandom output is considered secure for virtually all purposes, with the caveat that using it before the system gathers sufficient entropy for initialization may indeed produce low quality random numbers. The getrandom syscall helps with this situation; it uses the /dev/urandom sourc...