[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3a3f65d-9bbf-c509-3312-b6f19eaab5cb@amazon.de>
Date: Mon, 19 Jun 2023 22:37:59 +0200
From: Alexander Graf <graf@...zon.de>
To: "Jason A. Donenfeld" <Jason@...c4.com>,
Babis Chalios <bchalios@...zon.es>
CC: Theodore Ts'o <tytso@....edu>, <linux-kernel@...r.kernel.org>,
<mzxreary@...inter.de>, <xmarcalx@...zon.co.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 1/1] vmgenid: emit uevent when VMGENID updates
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
Powered by blists - more mailing lists