linux-kernel - Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d2566ff4-4203-4d12-a987-2a1cf94a484f@amazon.com>
Date: Fri, 26 Apr 2024 22:05:02 +0200
From: Alexander Graf <graf@...zon.com>
To: Babis Chalios <bchalios@...zon.es>, "Jason A. Donenfeld" <Jason@...c4.com>
CC: Lennart Poettering <mzxreary@...inter.de>, <linux-kernel@...r.kernel.org>,
	<stable@...r.kernel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, Theodore Ts'o
	<tytso@....edu>, "Cali, Marco" <xmarcalx@...zon.co.uk>, Arnd Bergmann
	<arnd@...db.de>, "rostedt@...dmis.org" <rostedt@...dmis.org>, "Christian
 Brauner" <brauner@...nel.org>, <linux@...mhuis.info>,
	<regressions@...ts.linux.dev>
Subject: Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when
 VMGENID updates"

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