Adding the Hyper-V people to this: On Wed, Feb 23, 2022 at 2:13 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > VM Generation ID is a feature from Microsoft, described at > <https://go.microsoft.com/fwlink/?LinkId=260709>, and supported by > Hyper-V and QEMU. Its usage is described in Microsoft's RNG whitepaper, > <https://aka.ms/win10rng>, as: > > If the OS is running in a VM, there is a problem that most > hypervisors can snapshot the state of the machine and later rewind > the VM state to the saved state. This results in the machine running > a second time with the exact same RNG state, which leads to serious > security problems. To reduce the window of vulnerability, Windows > 10 on a Hyper-V VM will detect when the VM state is reset, retrieve > a unique (not random) value from the hypervisor, and reseed the root > RNG with that unique value. This does not eliminate the > vulnerability, but it greatly reduces the time during which the RNG > system will produce the same outputs as it did during a previous > instantiation of the same VM state. > > Linux has the same issue, and given that vmgenid is supported already by > multiple hypervisors, we can implement more or less the same solution. > So this commit wires up the vmgenid ACPI notification to the RNG's newly > added add_vmfork_randomness() function. > > This driver builds on prior work from Adrian Catangiu at Amazon, and it > is my hope that that team can resume maintenance of this driver. If any of you have some experience with the Hyper-V side of this protocol, could you take a look at this and see if it matches the way this is supposed to work? It appears to work fine with QEMU's behavior, at least, but I know Hyper-V has a lot of additional complexities. Thanks, Jason
