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@xxxxxxxxx/
[2] https://lore.kernel.org/lkml/ZPXsuhXJhN9Q3hfH@xxxxxxxxx/
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
