Messages in this thread | | | Date | Thu, 24 Feb 2022 09:53:59 +0100 | Subject | Re: [PATCH RFC v1 0/2] VM fork detection for RNG | From | Alexander Graf <> |
| |
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@amazon.co.uk > Cc: acatan@amazon.com > Cc: graf@amazon.com > Cc: colmmacc@amazon.com > Cc: sblbir@amazon.com > Cc: raduweis@amazon.com > Cc: jannh@google.com > Cc: gregkh@linuxfoundation.org > Cc: tytso@mit.edu > > 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
| |