On Di, 23.04.24 03:21, Jason A. Donenfeld (Jason@xxxxxxxxx) wrote: Jason! Can you please explain to me what the precise problem is with the uevent? It doesn't leak any information about the actual vmgenid, it just lets userspace know that the machine was cloned, basically. What's the problem with that? I'd really like to understand? There are many usecases for this in the VM world, for example we'd like to hook things up so that various userspace managed concepts, such as DHCP leases, MAC addresses are automatically refreshed. This has no relationship to RNGs or anything like this, it's just an event we can handle in userspace to trigger address refreshes like this. Hence, why is the revert necessary? This was already in a released kernel, and we have started work on making use of this in systemd, and afaics this does not compromise the kernel RNG in even the remotest of ways, hence why is a revert necessary? From my usersace perspective it's just very very sad, that this simple, trivial interface we wanted to use, that was in a stable kernel is now gone again. Can you explain what the problem with this single-line trivial interface is? I really would like to understand! Lennart (BTW: even if the uevent would leak the vmgenid somehow to userspace — which it does not —, at least on qemu — i.e. one of the most relevant VM platforms — the vmgenid can be read directly from userspace by cat'ing /sys/firmware/qemu_fw_cfg/by_name/etc/vmgenid_guid/raw, i.e. it's not that well protected anyway). -- Lennart Poettering, Berlin
