Den sön 25 aug. 2024 kl 09:12 skrev Bryan Stenson <bryan.sten...@gmail.com>: > 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?
This is not the same. The VM fork thing relates more to when you snapshot a VM (both disk and ram) and copy it and then unsuspend it twice or more, then both disk and ram representation will be the same, and hence also the entropy pool, even though they are not strictly the same instance any longer. For a machine where RAM is not snapshotted but they boot from identical disks in the same kind of virtualization, there will be very few things that differ, perhaps only the clock differ by a small amount and mac address on ethernet interface at the most. So the suggestion here seems to be to detect if you as a VM have a different uuid than "last time" and if you do, then reseed the entropy pool as early as possible. Using https://man.openbsd.org/viornd.4 to pull a larger set of data at this time is probably a decent idea. >>> >>> 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. -- May the most significant bit of your life be positive.
