I've not tested this, but I wonder if adding unique entropy to each unique VM (post boot) would address this concern: https://man.openbsd.org/arc4random.9#enqueue_randomness
On Saturday, August 24, 2024, Jonas Böttiger <jonasboetti...@icloud.com> wrote: > Hi everyone, > > While implementing the new default random number generator for the Rust > standard library (https://github.com/rust-lang/rust/pull/129201), I’ve > noticed that OpenBSD does not appear to reseed its RNGs when a VM fork > occurs or multiple VMs are resumed from the same checkpoint. This can be > problematic because it means the VMs will all generate the same data, thus > weakening the security of cryptographic keys. To enable VM fork detection, > QEMU and some other VMs employ an ACPI device that provides a random VM ID > that can be used as input to entropy pools and a method to notify the > system of changes to that ID (see https://www.qemu.org/ > docs/master/specs/vmgenid.html). Both Linux and FreeBSD use this device > to protect their getrandom(2) implementation against VM forks ( > https://lwn.net/Articles/886004/). Linux additionally signals the newly > added vDSO getrandom syscall that a reseed of the userspace buffer is > necessary by updating a pool generation number in the kernel whenever > necessary (https://lwn.net/ml/linux-kernel/20230101162910.710293- > 1-ja...@zx2c4.com/). This strategy could be used for protecting > arc4random(3) as well so that its security is not diminished when compared > to getentropy. > > All the best, > Jonas >
