Received-SPF: pass (google.com: domain of linux-kernel+bounces-167508-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Subject: Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID
 updates"
Message-ID: <9cd37dda-29ea-4a4a-ae43-1cab0449ab0e@amazon.es>
Date: Fri, 3 May 2024 12:14:19 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
CC: Alexander Graf <graf@amazon.com>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>, Theodore Ts'o
	<tytso@mit.edu>, "Cali, Marco" <xmarcalx@amazon.co.uk>, Arnd Bergmann
	<arnd@arndb.de>, "rostedt@goodmis.org" <rostedt@goodmis.org>, "Christian
 Brauner" <brauner@kernel.org>, <linux@leemhuis.info>,
	<regressions@lists.linux.dev>, Lennart Poettering <mzxreary@0pointer.de>
References: <20240418114814.24601-1-Jason@zx2c4.com>
 <e09ce9fd-14cb-47aa-a22d-d295e466fbb4@amazon.com>
 <CAHmME9qKFraYWmzD9zKCd4oaMg6FyQGP5pL9bzZP4QuqV1O_Qw@mail.gmail.com>
 <ZieoRxn-On0gD-H2@gardel-login>
 <b819717c-74ea-4556-8577-ccd90e9199e9@amazon.com>
 <Ziujox51oPzZmwzA@zx2c4.com> <Zi9ilaX3254KL3Pp@gardel-login>
Content-Language: en-US
From: Babis Chalios <bchalios@amazon.es>
In-Reply-To: <Zi9ilaX3254KL3Pp@gardel-login>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jason,

Friendly ping?

IMHO Lennart, Alex and myself have raised (what I think to be) valid 
technical points regarding your concerns about your belief that the 
uevent mechanism is an ad-hoc mechanism that you don't consider viable.

Just to summarize:

* Upon VM clone, user space needs to adjust various components (DHCP 
leases, MAC addresses, etc.) that have nothing to do with PRNGs.
* The path of exposing the VM clone event via vgetrandom() (or any other 
interface of random.c) is simply wrong. The random subsystem is the 
natural component to inform about when cached entropy is stale. It 
should not be responsible for informing user space about VM clone 
events. IOW, "reseed your PRNGs" is not equivalent to "your VM has been 
cloned".

Given all this, it would help the discussion if you explained why you 
believe random.c should propagate VM clone events and how.

If you don't believe that, could you explain what is the problem with 
the proposed uevent mechanism? Personally, I agree with Lennart that 
VMGenID is a generic ACPI device built for exactly this purpose. VMGenID 
is not an "ad-hoc driver". It is a standard which is supported by most 
(all?) major VMMs out there today and its whole purpose is to deliver 
inside the VM a notification that it was cloned.

Cheers,
Babis