Re: [PATCH RFC v1 0/2] VM fork detection for RNG

[Alexander Graf <graf@amazon.com>]

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