public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	linux-s390@vger.kernel.org, adrian@parity.io
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	dwmw@amazon.co.uk, acatan@amazon.com, graf@amazon.com,
	colmmacc@amazon.com, sblbir@amazon.com, raduweis@amazon.com,
	jannh@google.com, gregkh@linuxfoundation.org, tytso@mit.edu
Subject: [PATCH RFC v1 0/2] VM fork detection for RNG
Date: Wed, 23 Feb 2022 14:12:29 +0100	[thread overview]
Message-ID: <20220223131231.403386-1-Jason@zx2c4.com> (raw)

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.

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


             reply	other threads:[~2022-02-23 13:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 13:12 Jason A. Donenfeld [this message]
2022-02-23 13:12 ` [PATCH RFC v1 1/2] random: add mechanism for VM forks to reinitialize crng Jason A. Donenfeld
2022-02-23 23:16   ` Eric Biggers
2022-02-24  0:54     ` Jason A. Donenfeld
2022-02-24  1:27       ` Eric Biggers
2022-02-24 11:15         ` Jason A. Donenfeld
2022-02-23 13:12 ` [PATCH RFC v1 2/2] drivers/virt: add vmgenid driver for reinitializing RNG Jason A. Donenfeld
2022-02-23 16:36   ` Jason A. Donenfeld
2022-02-23 16:08 ` [PATCH RFC v1 0/2] VM fork detection for RNG Jason A. Donenfeld
2022-02-23 16:19   ` Jason A. Donenfeld
     [not found]   ` <2653b6c7-a851-7a48-f1f8-3bde742a0c9f@redhat.com>
2022-02-24 10:43     ` Jason A. Donenfeld
2022-02-24 10:55     ` Daniel P. Berrangé
2022-02-24 10:57       ` Jason A. Donenfeld
2022-02-25 10:40         ` Michael S. Tsirkin
2022-02-24  8:53 ` Alexander Graf
2022-02-24 10:43   ` Daniel P. Berrangé
2022-02-24 11:35     ` Alexander Graf
2022-02-24 10:53   ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220223131231.403386-1-Jason@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=acatan@amazon.com \
    --cc=adrian@parity.io \
    --cc=colmmacc@amazon.com \
    --cc=dwmw@amazon.co.uk \
    --cc=graf@amazon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=raduweis@amazon.com \
    --cc=sblbir@amazon.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox