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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <234d7952-0379-e3d9-5e02-5eba171024a0@amazon.com>
Date:   Thu, 24 Feb 2022 09:53:59 +0100
From:   Alexander Graf <graf@...zon.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        <linux-kernel@...r.kernel.org>, <linux-crypto@...r.kernel.org>,
        <qemu-devel@...gnu.org>, <kvm@...r.kernel.org>,
        <linux-s390@...r.kernel.org>, <adrian@...ity.io>
CC:     <dwmw@...zon.co.uk>, <acatan@...zon.com>, <colmmacc@...zon.com>,
        <sblbir@...zon.com>, <raduweis@...zon.com>, <jannh@...gle.com>,
        <gregkh@...uxfoundation.org>, <tytso@....edu>
Subject: Re: [PATCH RFC v1 0/2] VM fork detection for RNG

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@...zon.co.uk
> Cc: acatan@...zon.com
> Cc: graf@...zon.com
> Cc: colmmacc@...zon.com
> Cc: sblbir@...zon.com
> Cc: raduweis@...zon.com
> Cc: jannh@...gle.com
> Cc: gregkh@...uxfoundation.org
> Cc: tytso@....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