Re: [PATCH v3] drivers/virt: vmgenid: add vm generation id driver

[Catangiu, Adrian Costin]

+ 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
    underlying VM
      or container goes through a snapshot restore event which is
    otherwise
      transparent 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 <oridgar@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.