Messages in this thread | | | Date | Fri, 26 Apr 2024 22:05:02 +0200 | Subject | Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates" | From | Alexander Graf <> |
| |
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
| |