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: <9cd37dda-29ea-4a4a-ae43-1cab0449ab0e@amazon.es>
Date: Fri, 3 May 2024 12:14:19 +0200
From: Babis Chalios <bchalios@...zon.es>
To: "Jason A. Donenfeld" <Jason@...c4.com>
CC: Alexander Graf <graf@...zon.com>, <linux-kernel@...r.kernel.org>,
	<stable@...r.kernel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, Theodore Ts'o
	<tytso@....edu>, "Cali, Marco" <xmarcalx@...zon.co.uk>, Arnd Bergmann
	<arnd@...db.de>, "rostedt@...dmis.org" <rostedt@...dmis.org>, "Christian
 Brauner" <brauner@...nel.org>, <linux@...mhuis.info>,
	<regressions@...ts.linux.dev>, Lennart Poettering <mzxreary@...inter.de>
Subject: Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID
 updates"

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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ