From: Alexander Graf <graf@amazon.com>
To: Babis Chalios <bchalios@amazon.es>,
"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>,
<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>
Subject: Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates"
Date: Fri, 26 Apr 2024 22:05:02 +0200 [thread overview]
Message-ID: <d2566ff4-4203-4d12-a987-2a1cf94a484f@amazon.com> (raw)
In-Reply-To: <1f09319c-56e6-44d7-9175-c6307089447b@amazon.es>
On 26.04.24 15:43, Babis Chalios wrote:
> Hi Jason,
>
> On 4/26/24 14:52, Jason A. Donenfeld wrote:
>> I don't think adding UAPI to an individual device driver like this is a
>> good approach especially considering that the virtio changes we
>> discussed some time ago will likely augment this and create another
>> means of a similar notification. And given that this intersects with
>> other userspace-oriented work I hope to get back to pretty soon, I think
>> introducing some adhoc mechanism like this adds clutter and isn't the
>> ideal way forward.
>>
>
> Correct me if I'm wrong, but the virtio changes were meant to mean
> "please
> reseed your PRNGs". That's why we wanted to route them via random.c. We
> designed them specifically so that virtio-rng would be only one of the
> potential
> systems that would emit such notifications, whereas other systems
> might have
> nothing to do with VM events.
>
> With that in mind, could you describe how these events would be useful
> to the
> use case of Lennart? systemd does not need a notification every time
> the system
> believes PRNGs need to be reseeded. It explicitly needs a notification
> when a VM
> was cloned. This has nothing to do with PRNGs and I don't believe
> random.c,
> virtio-rng, or vgetrand() should be responsible for delivering this.
I second this. A VM clone event may be one of multiple events that can
cause an RNG reseed event. This is what Babis' patches to propagate such
an event[1] implemented: A new type of multiplexed event that feeds from
multiple sources; most notably *not* from VMGenID.
Due your reluctance to enable user space PRNGs to get any notion of
reseed events [2], we have since abandoned that whole RNG reseed event
approach: Going forward, for our environments, we'll simply mandate that
PRNGs always mix in randomness that is guaranteed different post-clone
(such as RDRAND). You want a clone safe system? Use one that does (fast
and non-broken) RDRAND.
However, VM clone events are useful for other situations as all of us
outlined multiple times in this and previous threads. While you can use
VM clone events as a source for RNG reseed events, you can not use RNG
reseed events (or a snapshot safe RNG source like /dev/random) as
indicator for VM clones, because they will trigger more often and hence
cause undesired side effects. You may want a reseed every 60s, but
surely don't want a new MAC address every 60 seconds, right? :)
Now, theoretically I can see some merit for a single, abstracted event
source for VM clones over a per-driver one. But practically, between
VMGenID on ACPI and Device Tree systems, there are very for platforms
that care about safe VM snapshots and wouldn't "just work". The only one
I can think of atm is s390x. I don't know if an abstraction - like
another driver that simply proxies notifications - would be worth it. Or
if in that case we'd just expand the very same vmgenid driver to that
other one-off platform that happens to run without DT or ACPI.
So, overall, I still don't see any better path forward to get a "VM
cloned" event into systemd than the uevent.
Jason, could you please outline how your "other userspace-oriented work
you hope to get back to soon" would help with the systemd use case?
Alex
[1] https://lore.kernel.org/lkml/20230823090107.65749-1-bchalios@amazon.es/
[2] https://lore.kernel.org/lkml/ZPXsuhXJhN9Q3hfH@zx2c4.com/
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:[~2024-04-26 20:05 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
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 [this message]
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=d2566ff4-4203-4d12-a987-2a1cf94a484f@amazon.com \
--to=graf@amazon.com \
--cc=Jason@zx2c4.com \
--cc=arnd@arndb.de \
--cc=bchalios@amazon.es \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=mzxreary@0pointer.de \
--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.