lkml.org 
[lkml]   [2024]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates"
From

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


\
 
 \ /
  Last update: 2024-05-27 18:06    [W:1.239 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site