Re: [PATCH v3] drivers/virt: vmgenid: add vm generation id driver
+ 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 '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.
Re: [PATCH v3] drivers/virt: vmgenid: add vm generation id driver
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. 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. - 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. 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. 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 's proposal https://lkml.org/lkml/2018/3/1/498 - Future improvements Ideally we would want the driver to register itself based on devices' _CID and not _HID, but unfortunately I couldn't find a way to do that. The problem is that ACPI device matching is done by '__acpi_match_device()' which exclusively looks at 'acpi_hardware_id *hwid'. There is a path for platform devices to match on _CID when _HID is 'PRP0001' - but this is not the case for the Qemu vmgenid device. Guidance and help here would be greatly appreciated. Signed-off-by: Adrian Catangiu --- v1 -> v2: - expose to userspace a monotonically increasing u32 Vm Gen Counter instead of the hw VmGen UUID - since the hw/hypervisor-provided 128-bit UUID is not public anymore, add it to the kernel RNG as device randomness - insert driver page containing Vm Gen Counter in the user vma in the driver's mmap handler instead of using a fault handler - turn driver into a misc device driver to auto-create /dev/vmgenid - change ioctl arg to avoid leaking kernel structs to userspace - update documentation - various nits - rebase on top of linus latest v2 -> v3: - separate the core driver logic and interface, from the ACPI device. The ACPI vmgenid device is now one possible backend. - fix issue when timeout=0 in VMGENID_WAIT_WATCHERS - add locking to avoid races between fs ops handlers and hw irq driven generation updates - change VMGENID_WAIT_WATCHERS ioctl so if the current caller is outdated or a generation change happens while waiting (thus making current caller outdated), the ioctl returns -EINTR to signal the user to handle event and retry. Fixes blocking on oneself. - add VMGENID_FORCE_GEN_UPDATE ioctl conditioned by CAP_CHECKPOINT_RESTORE capability, through which software can force generation bump. --- Documentation/virt/vmgenid.rst | 240 +++ drivers/virt/Kconfig | 17 ++ drivers/virt/Makefile | 1 + drivers/virt/vmgenid.c | 435 + include/uapi/linux/vmgenid.h | 14 ++ 5 files changed, 707 insertions(+) create mode 100644 Documentation/virt/vmgenid.rst create mode 100644 drivers/virt/vmgenid.c create mode 100644 include/uapi/linux/vmgenid.h [...] diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig index 80c5f9c1..5d5f37b 100644 --- a/drivers/virt/Kconfig +++ b/drivers/virt/Kconfig @@ -13,6 +13,23 @@ menuconfig VIRT_DRIVERS if VIRT_DRIVERS +config VMGENID + tristate "Virtual Machine Generation ID driver" + depends on ACPI I think you want to
Re: [PATCH v3] drivers/virt: vmgenid: add vm generation id driver
"Catangiu, Adrian Costin" writes: > - 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 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? > - 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 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. > 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 's proposal > https://lkml.org/lkml/2018/3/1/498 Eric
Re: [PATCH v3] drivers/virt: vmgenid: add vm generation id driver
Hi Adrian, Usually each version of a patch is a separate e-mail thread On Fri, Nov 27, 2020 at 08:26:02PM +0200, 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. > > 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. > > - 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. 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. > > 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 's proposal > https://lkml.org/lkml/2018/3/1/498 > > - Future improvements > > Ideally we would want the driver to register itself based on devices' > _CID and not _HID, but unfortunately I couldn't find a way to do that. > The problem is that ACPI device matching is done by > '__acpi_match_device()' which exclusively looks at > 'acpi_hardware_id *hwid'. > > There is a path for platform devices to match on _CID when _HID is > 'PRP0001' - but this is not the case for the Qemu vmgenid device. > > Guidance and help here would be greatly appreciated. > > Signed-off-by: Adrian Catangiu > > --- Please put the history in the descending order next time v2 -> v3: ... v1 -> v2: ... > v1 -> v2: > > - expose to userspace a monotonically increasing u32 Vm Gen Counter > instead of the hw VmGen UUID > - since the hw/hypervisor-provided 128-bit UUID is not public > anymore, add it to the kernel RNG as device randomness > - insert driver page containing Vm Gen Counter in the user vma in > the driver's mmap handler instead of using a fault handler > - turn driver into a misc device driver to auto-create /dev/vmgenid > - change ioctl arg to avoid leaking kernel structs to userspace > - update documentation > - various nits > - rebase on top of linus latest > > v2 -> v3: > > - separate the core driver logic and interface, from the ACPI device. > The ACPI vmgenid device is now one possible backend. > - fix issue when timeout=0 in VMGENID_WAIT_WATCHERS > - add locking to avoid races between fs ops handlers and hw irq > driven generation updates > - change VMGENID_WAIT_WATCHERS ioctl so if the current caller is > outdated or a generation change happens while waiting (thus making > current caller outdated), the ioctl returns -EINTR to signal the > user to handle event and retry. Fixes blocking on oneself. > - add VMGENID_FORCE_GEN_UPDATE ioctl conditioned by > CAP_CHECKPOINT_RESTORE capability, through which software can force > generation bump. > --- > Documentation/virt/vmgenid.rst | 240 +++ > drivers/virt/Kconfig | 17 ++ > drivers/virt/Makefile | 1 + > drivers/virt/vmgenid.c | 435 > + > include/uapi/linux/vmgenid.h | 14 ++ > 5 files changed, 707 insertions(+) > create mode 100644 Documentation/virt/vmgenid.rst > create mode 100644 drivers/virt/vmgenid.c > create mode
[PATCH v3] drivers/virt: vmgenid: add vm generation id driver
- 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. 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. - 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. 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. 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 's proposal https://lkml.org/lkml/2018/3/1/498 - Future improvements Ideally we would want the driver to register itself based on devices' _CID and not _HID, but unfortunately I couldn't find a way to do that. The problem is that ACPI device matching is done by '__acpi_match_device()' which exclusively looks at 'acpi_hardware_id *hwid'. There is a path for platform devices to match on _CID when _HID is 'PRP0001' - but this is not the case for the Qemu vmgenid device. Guidance and help here would be greatly appreciated. Signed-off-by: Adrian Catangiu --- v1 -> v2: - expose to userspace a monotonically increasing u32 Vm Gen Counter instead of the hw VmGen UUID - since the hw/hypervisor-provided 128-bit UUID is not public anymore, add it to the kernel RNG as device randomness - insert driver page containing Vm Gen Counter in the user vma in the driver's mmap handler instead of using a fault handler - turn driver into a misc device driver to auto-create /dev/vmgenid - change ioctl arg to avoid leaking kernel structs to userspace - update documentation - various nits - rebase on top of linus latest v2 -> v3: - separate the core driver logic and interface, from the ACPI device. The ACPI vmgenid device is now one possible backend. - fix issue when timeout=0 in VMGENID_WAIT_WATCHERS - add locking to avoid races between fs ops handlers and hw irq driven generation updates - change VMGENID_WAIT_WATCHERS ioctl so if the current caller is outdated or a generation change happens while waiting (thus making current caller outdated), the ioctl returns -EINTR to signal the user to handle event and retry. Fixes blocking on oneself. - add VMGENID_FORCE_GEN_UPDATE ioctl conditioned by CAP_CHECKPOINT_RESTORE capability, through which software can force generation bump. --- Documentation/virt/vmgenid.rst | 240 +++ drivers/virt/Kconfig | 17 ++ drivers/virt/Makefile | 1 + drivers/virt/vmgenid.c | 435 + include/uapi/linux/vmgenid.h | 14 ++ 5 files changed, 707 insertions(+) create mode 100644 Documentation/virt/vmgenid.rst create mode 100644 drivers/virt/vmgenid.c create mode 100644 include/uapi/linux/vmgenid.h diff --git a/Documentation/virt/vmgenid.rst b/Documentation/virt/vmgenid.rst new file mode 100644 index 000..b6a9f8d --- /dev/null +++ b/Documentation/virt/vmgenid.rst @@ -0,0 +1,240 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +VMGENID + + +The VM Generation ID is a feature defined by Microsoft (paper: +http://go.microsoft.com/fwlink/?LinkId=260709) and supported by +multiple hypervisor
