Per Theo's comment here, maybe this really doesn't matter : https://marc.info/?l=openbsd-tech&m=172426918805083&w=2
Are you actually seeing identical values from arc4random(3) from VMs launched from the same snapshot? On Saturday, August 24, 2024, Bryan Stenson <bryan.sten...@gmail.com> wrote: > 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 >> >
