kern/58632: getentropy(2) and arc4random(3) do not reseed on VM fork

[jonas.boettiger%icloud.com@localhost]

>Number:         58632
>Category:       kern
>Synopsis:       getentropy(2) and arc4random(3) do not reseed on VM fork
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 24 14:20:00 +0000 2024
>Originator:     Jonas Böttiger
>Release:        
>Organization:
rust-lang
>Environment:
>Description:
Both getentropy(2) and arc4random(3) do not reseed when a VM is cloned or multiple VMs are resumed from the same snapshot, so the new VMs will all produce the same or similar output from getentropy(2) and arc4random(3), which could be used for attacks on keys used for cryptography.
>How-To-Repeat:

>Fix:
Multiple VMs ? e.g. QEMU ? expose a special VM generation ID device via the ACPI that allows retrieving a randomized VM ID and notifies the system whenever this changes. This ID can then be used as input to the RNG, ensuring randomization.

The newly introduced vDSO version of getrandom(2) on Linux also uses an entropy pool generation counter that is updated by the kernel whenever necessary to ensure that the userspace RNGs also perform a reseed. This strategy could allow resolving this issue for arc4random(3) as well.

https://www.qemu.org/docs/master/specs/vmgenid.html
https://lwn.net/Articles/886004/
https://lwn.net/ml/linux-kernel/20230101162910.710293-1-Jason%zx2c4.com@localhost/