From: Lennart Poettering <mzxreary@0pointer.de>
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>,
Babis Chalios <bchalios@amazon.es>, 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
Subject: Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates"
Date: Tue, 23 Apr 2024 14:23:35 +0200 [thread overview]
Message-ID: <ZieoRxn-On0gD-H2@gardel-login> (raw)
In-Reply-To: <CAHmME9qKFraYWmzD9zKCd4oaMg6FyQGP5pL9bzZP4QuqV1O_Qw@mail.gmail.com>
On Di, 23.04.24 03:21, Jason A. Donenfeld (Jason@zx2c4.com) wrote:
Jason!
Can you please explain to me what the precise problem is with the
uevent? It doesn't leak any information about the actual vmgenid, it
just lets userspace know that the machine was cloned,
basically. What's the problem with that? I'd really like to
understand?
There are many usecases for this in the VM world, for example we'd
like to hook things up so that various userspace managed concepts,
such as DHCP leases, MAC addresses are automatically refreshed.
This has no relationship to RNGs or anything like this, it's just an
event we can handle in userspace to trigger address refreshes like
this.
Hence, why is the revert necessary? This was already in a released
kernel, and we have started work on making use of this in systemd, and
afaics this does not compromise the kernel RNG in even the remotest of
ways, hence why is a revert necessary? From my usersace perspective
it's just very very sad, that this simple, trivial interface we wanted
to use, that was in a stable kernel is now gone again.
Can you explain what the problem with this single-line trivial
interface is? I really would like to understand!
Lennart
(BTW: even if the uevent would leak the vmgenid somehow to userspace —
which it does not —, at least on qemu — i.e. one of the most relevant
VM platforms — the vmgenid can be read directly from userspace by
cat'ing /sys/firmware/qemu_fw_cfg/by_name/etc/vmgenid_guid/raw,
i.e. it's not that well protected anyway).
--
Lennart Poettering, Berlin
next prev parent reply other threads:[~2024-04-23 12:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 11:48 [PATCH] Revert "vmgenid: emit uevent when VMGENID updates" Jason A. Donenfeld
2024-04-18 12:46 ` Greg Kroah-Hartman
2024-04-22 7:51 ` [REGRESSION] " Alexander Graf
2024-04-23 1:21 ` Jason A. Donenfeld
2024-04-23 6:56 ` Alexander Graf
2024-04-23 12:23 ` Lennart Poettering [this message]
2024-04-26 11:33 ` Alexander Graf
2024-04-26 12:52 ` Jason A. Donenfeld
2024-04-26 13:43 ` Babis Chalios
2024-04-26 20:05 ` Alexander Graf
2024-04-29 9:04 ` Lennart Poettering
2024-05-03 10:14 ` Babis Chalios
2024-04-26 14:20 ` Linux regression tracking (Thorsten Leemhuis)
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=ZieoRxn-On0gD-H2@gardel-login \
--to=mzxreary@0pointer.de \
--cc=Jason@zx2c4.com \
--cc=arnd@arndb.de \
--cc=bchalios@amazon.es \
--cc=brauner@kernel.org \
--cc=graf@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.