Message-Id: <20220224133906.751587-1-Jason@zx2c4.com>
Date:   Thu, 24 Feb 2022 14:39:04 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     linux-hyperv@...r.kernel.org, kvm@...r.kernel.org,
        linux-crypto@...r.kernel.org, qemu-devel@...gnu.org,
        linux-kernel@...r.kernel.org
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>, adrian@...ity.io,
        dwmw@...zon.co.uk, graf@...zon.com, colmmacc@...zon.com,
        raduweis@...zon.com, berrange@...hat.com, lersek@...hat.com,
        imammedo@...hat.com, ehabkost@...hat.com, ben@...portsystems.com,
        mst@...hat.com, kys@...rosoft.com, haiyangz@...rosoft.com,
        sthemmin@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com,
        linux@...inikbrodowski.net, ebiggers@...nel.org, ardb@...nel.org,
        jannh@...gle.com, gregkh@...uxfoundation.org, tytso@....edu
Subject: [PATCH v3 0/2] VM fork detection for RNG

This small series picks up work from Amazon that seems to have stalled
out last year around this time: listening for the vmgenid ACPI
notification, and using it to "do something." Last year, folks proposed
a complicated userspace mmap chardev, which was frought with difficulty
and evidently abandoned. This year, instead, I have something much
simpler in mind: simply using those ACPI notifications to tell the RNG
to reinitialize safely, so we don't repeat random numbers in cloned,
forked, or rolled-back VM instances.

This series consists of two patches. The first one adds the right hooks
into the actual RNG, and the second is a driver for the ACPI notification.

Here's a little screencast showing it in action: https://data.zx2c4.com/vmgenid-appears-to-work.gif

As a side note, this series intentionally does _not_ focus on
notification of these events to userspace or to other kernel consumers.
Since these VM fork detection events first need to hit the RNG, we can
later talk about what sorts of notifications or mmap'd counters the RNG
should be making accessible to elsewhere. But that's a different sort of
project and ties into a lot of more complicated concerns beyond this
more basic patchset. So hopefully we can keep the discussion rather
focused here to this ACPI business.

Changes v2->v3:
- [Eric] Always put generation ID through the input pool, and then re-extract.
- [Lazlo] The ACPI bytes are just an opaque binary blob, rather than a real UUID.
Changes v1->v2:
- [Ard] Correct value of MODULE_LICENSE().
- [Ard] Use ordinary memory accesses instead of memcpy_fromio.
- [Ard] Make module a tristate and set MODULE_DEVICE_TABLE().
- [Ard] Free buffer after using.
- Use { } instead of { "", 0 }.
- Clean up interface into RNG.
- Minimize ACPI driver a bit.

In addition to the usual suspects, I'm CCing the original team from
Amazon who proposed this last year and the QEMU developers who added it
there, as well as the kernel Hyper-V maintainers, since this is
technically a Microsoft-proposed thing, though QEMU now implements it.

Cc: adrian@...ity.io
Cc: dwmw@...zon.co.uk
Cc: graf@...zon.com
Cc: colmmacc@...zon.com
Cc: raduweis@...zon.com
Cc: berrange@...hat.com
Cc: lersek@...hat.com
Cc: imammedo@...hat.com
Cc: ehabkost@...hat.com
Cc: ben@...portsystems.com
Cc: mst@...hat.com
Cc: kys@...rosoft.com
Cc: haiyangz@...rosoft.com
Cc: sthemmin@...rosoft.com
Cc: wei.liu@...nel.org
Cc: decui@...rosoft.com
Cc: linux@...inikbrodowski.net
Cc: ebiggers@...nel.org
Cc: ardb@...nel.org
Cc: jannh@...gle.com
Cc: gregkh@...uxfoundation.org
Cc: tytso@....edu

Jason A. Donenfeld (2):
  random: add mechanism for VM forks to reinitialize crng
  virt: vmgenid: introduce driver for reinitializing RNG on VM fork

 drivers/char/random.c  |  50 ++++++++++++-----
 drivers/virt/Kconfig   |   9 +++
 drivers/virt/Makefile  |   1 +
 drivers/virt/vmgenid.c | 121 +++++++++++++++++++++++++++++++++++++++++
 include/linux/random.h |   1 +
 5 files changed, 167 insertions(+), 15 deletions(-)
 create mode 100644 drivers/virt/vmgenid.c

-- 
2.35.1

Powered by blists - more mailing lists