From: Souradeep Chakrabarti <souradch.linux@xxxxxxxxx> Jason A. Donenfeld <Jason@xxxxxxxxx> Sent: Saturday, February 26, 2022 2:07 PM > > 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. > > It can be used from qemu via the `-device vmgenid,guid=auto` parameter. > After setting that, use `savevm` in the monitor to save the VM state, > then quit QEMU, start it again, and use `loadvm`. That will trigger this > driver's notify function, which hands the new UUID to the RNG. This is > described in <https://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/vmgenid.txt>. > And there are hooks for this in libvirt as well, described in > <https://libvirt.org/formatdomain.html#general-metadata>. > > Note, however, that the treatment of this as a UUID is considered to be > an accidental QEMU nuance, per > <https://github.com/libguestfs/virt-v2v/blob/master/docs/vm-generation-id-across-hypervisors.txt>, > so this driver simply treats these bytes as an opaque 128-bit binary > blob, as per the spec. This doesn't really make a difference anyway, > considering that's how it ends up when handed to the RNG in the end. > > Cc: Alexander Graf <graf@xxxxxxxxxx> > Cc: Adrian Catangiu <adrian@xxxxxxxxx> > Cc: Daniel P. Berrangé <berrange@xxxxxxxxxx> > Cc: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> > Cc: Wei Yongjun <weiyongjun1@xxxxxxxxxx> > Reviewed-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> The patch has been successfully verified in Hyper-V. I have used checkpoint to create snapshot and restarted the VM multiple times from the same snapshot by applying it each time. To confirm the unique VM generation id, printk has been used to print the value each time. Tested-by: Souradeep Chakrabarti <souradch.linux@xxxxxxxxx> > --- > Changes v4->v5: > - [Greg] Use module_acpi_driver instead of writing my own code. > - [Alex] Match on _CID instead of _HID. > - Prefer Y over M but still allow M, to handle initramfs reseeds. > - [Wei] Use IS_ERR instead of NULL check with devm_memremap. > > MAINTAINERS | 1 + > drivers/virt/Kconfig | 11 +++++ > drivers/virt/Makefile | 1 + > drivers/virt/vmgenid.c | 100 +++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 113 insertions(+) > create mode 100644 drivers/virt/vmgenid.c >
