+ Eric W. Biederman Eric's email was filtered by my server for some reason so I can't directly reply to it, this is the closest thread relative I could answer on.
On 01/12/2020 12:00, Eric W. Biederman wrote: > > > On 27.11.20 19:26, Catangiu, Adrian Costin wrote: >> - Background >> >> The VM Generation ID is a feature defined by Microsoft (paper: >> http://go.microsoft.com/fwlink/?LinkId=260709) and supported by >> multiple hypervisor vendors. >> >> The feature is required in virtualized environments by apps that work >> with local copies/caches of world-unique data such as random values, >> uuids, monotonically increasing counters, etc. >> Such apps can be negatively affected by VM snapshotting when the VM >> is either cloned or returned to an earlier point in time. >> > How does this differ from /proc/sys/kernel/random/boot_id? The boot_id only changes at OS boot whereas we need the generation id to change _while_ the system/guest-os is running - generation changes because underlyingVM or container goes through a snapshot restore event which is otherwisetransparent to guest system. >> >> The VM Generation ID is a simple concept meant to alleviate the issue >> by providing a unique ID that changes each time the VM is restored >> from a snapshot. The hw provided UUID value can be used to >> differentiate between VMs or different generations of the same VM. >> > Does the VM generation ID change in a running that effectively things it > is running? Yes, the generation id changes while guest OS is running, the generation change itself is what lets the guest OS and guest userspace know there's been a VM or container snapshot restore event. >> >> - Problem >> >> The VM Generation ID is exposed through an ACPI device by multiple >> hypervisor vendors but neither the vendors or upstream Linux have no >> default driver for it leaving users to fend for themselves. >> >> Furthermore, simply finding out about a VM generation change is only >> the starting point of a process to renew internal states of possibly >> multiple applications across the system. This process could benefit >> from a driver that provides an interface through which orchestration >> can be easily done. >> >> - Solution >> >> This patch is a driver that exposes a monotonic incremental Virtual >> Machine Generation u32 counter via a char-dev FS interface. > Earlier it was a UUID now it is 32bit number? The generation id exposed to userspace is a 32bit monotonic incremental counter. This counter is internally driven by the acpi vmgenid device. The 128-bit vmgenid-device-provided UUID is only used internally by the driver. I will make all of this clearer in the next patch version. >> The FS >> interface provides sync and async VmGen counter updates notifications. >> It also provides VmGen counter retrieval and confirmation mechanisms. >> >> The generation counter and the interface through which it is exposed >> are available even when there is no acpi device present. >> >> When the device is present, the hw provided UUID is not exposed to >> userspace, it is internally used by the driver to keep accounting for >> the exposed VmGen counter. The counter starts from zero when the >> driver is initialized and monotonically increments every time the hw >> UUID changes (the VM generation changes). >> On each hw UUID change, the new hypervisor-provided UUID is also fed >> to the kernel RNG. > Should this be a hotplug even rather than a new character device? > > Without plugging into udev and the rest of the hotplug infrastructure > I suspect things will be missed. That's a good idea, I will look into it. >> >> If there is no acpi vmgenid device present, the generation changes are >> not driven by hw vmgenid events but can be driven by software through >> a dedicated driver ioctl. >> >> This patch builds on top of Or Idgar <orid...@gmail.com>'s proposal >> https://lkml.org/lkml/2018/3/1/498 > Eric > Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
