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
