Hey Jason,
On 23.02.22 14:12, Jason A. Donenfeld wrote:
This small series picks up work from Amazon that seems to have stalled
out later year around this time: listening for the vmgenid ACPI
notification, and using it to "do something." Last year, that something
involved a complicated userspace mmap chardev, which seems frought with
difficulty. This year, 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 is a rather
straightforward addition to random.c, which I feel fine about. The
second patch is the reason this is just an RFC: it's a cleanup of the
ACPI driver from last year, and I don't really have much experience
writing, testing, debugging, or maintaining these types of drivers.
Ideally this thread would yield somebody saying, "I see the intent of
this; I'm happy to take over ownership of this part." That way, I can
focus on the RNG part, and whoever steps up for the paravirt ACPI part
can focus on that.
As a final 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.
The main problem with VMGenID is that it is inherently racy. There will
always be a (short) amount of time where the ACPI notification is not
processed, but the VM could use its RNG to for example establish TLS
connections.
Hence we as the next step proposed a multi-stage quiesce/resume
mechanism where the system is aware that it is going into suspend - can
block network connections for example - and only returns to a fully
functional state after an unquiesce phase:
https://github.com/systemd/systemd/issues/20222
Looking at the issue again, it seems like we completely missed to follow
up with a PR to implement that functionality :(.
What exact use case do you have in mind for the RNG/VMGenID update? Can
you think of situations where the race is not an actual concern?
Alex
Cc: dwmw@xxxxxxxxxxxx
Cc: acatan@xxxxxxxxxx
Cc: graf@xxxxxxxxxx
Cc: colmmacc@xxxxxxxxxx
Cc: sblbir@xxxxxxxxxx
Cc: raduweis@xxxxxxxxxx
Cc: jannh@xxxxxxxxxx
Cc: gregkh@xxxxxxxxxxxxxxxxxxx
Cc: tytso@xxxxxxx
Jason A. Donenfeld (2):
random: add mechanism for VM forks to reinitialize crng
drivers/virt: add vmgenid driver for reinitializing RNG
drivers/char/random.c | 58 ++++++++++++++++++
drivers/virt/Kconfig | 8 +++
drivers/virt/Makefile | 1 +
drivers/virt/vmgenid.c | 133 +++++++++++++++++++++++++++++++++++++++++
include/linux/random.h | 1 +
5 files changed, 201 insertions(+)
create mode 100644 drivers/virt/vmgenid.c
--
2.35.1
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
