From: Alexander Graf <graf@amazon.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Babis Chalios <bchalios@amazon.es>
Cc: Theodore Ts'o <tytso@mit.edu>, <linux-kernel@vger.kernel.org>,
<mzxreary@0pointer.de>, <xmarcalx@amazon.co.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 1/1] vmgenid: emit uevent when VMGENID updates
Date: Mon, 19 Jun 2023 22:37:59 +0200 [thread overview]
Message-ID: <b3a3f65d-9bbf-c509-3312-b6f19eaab5cb@amazon.de> (raw)
In-Reply-To: <CAHmME9pVLD-U+iYfv7=HBufRtaSkBmCRpKLH8pbvPNkgozE3cg@mail.gmail.com>
Hey Jason,
On 19.06.23 22:30, Jason A. Donenfeld wrote:
> Like the other patch, and as discussed before too, I don't think this
> has any business being part of (virtual) hardware drivers, and instead
> belongs in random.c, which might receive these notifications from a
> variety of devices, and can thus synchronize things accordingly.
> Please stop posting more of these same approaches. Same nack as the
> other ones.
Could you please elaborate what other devices you envision emitting
"This VM was cloned, you MAC address may now collide" style events?
What we talked about at LPC was an orthogonal interface that allows user
space to receive reseed events when either the kernel, an RNG device or
anything else in the system wants to say "Your cached randomness may be
compromised, please fetch some new".
This patch is not that interface. It's an event meant for systemd (and
other system software) to know exclusively about VM clone events. That
system software can not use the reseed event above: Just imagine getting
a new MAC address every 5 minutes. So here we really just want to know
the vmgenid changed, no more, no less.
Alex
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
next prev parent reply other threads:[~2023-06-19 20:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 9:51 [PATCH 0/1] User space notifications about VM cloning Babis Chalios
2023-05-31 9:51 ` [PATCH 1/1] vmgenid: emit uevent when VMGENID updates Babis Chalios
2023-06-19 9:14 ` Alexander Graf
2023-06-19 15:48 ` Lennart Poettering
2023-06-19 20:30 ` Jason A. Donenfeld
2023-06-19 20:37 ` Alexander Graf [this message]
2023-06-20 10:27 ` Babis Chalios
2023-06-20 11:28 ` Lennart Poettering
2023-11-14 12:51 ` Alexander Graf
2023-06-16 15:07 ` [PATCH 0/1] User space notifications about VM cloning Babis Chalios
2023-06-28 11:13 ` Alexander Graf
2023-06-28 11:22 ` Greg KH
2023-06-28 11:36 ` Jason A. Donenfeld
2023-06-28 11:47 ` Greg KH
2023-06-28 16:08 ` Greg KH
2023-06-28 16:27 ` Jason A. Donenfeld
2023-06-28 16:53 ` Amit Shah
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=b3a3f65d-9bbf-c509-3312-b6f19eaab5cb@amazon.de \
--to=graf@amazon.de \
--cc=Jason@zx2c4.com \
--cc=bchalios@amazon.es \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mzxreary@0pointer.de \
--cc=tytso@mit.edu \
--cc=xmarcalx@amazon.co.uk \
/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