Err... On Mon, May 02, 2022 at 08:04:21PM +0200, Jason A. Donenfeld wrote: > This doesn't work, because you could have memory-A split into memory-A.1 > and memory-A.2, and both A.2 and A.1 would ++counter, and wind up with > the same new value "2". The solution is to instead have the hypervisor > pass a unique value and a counter. We currently have a 16 byte unique > value from the hypervisor, which I'm keeping as a kernel space secret > for the RNG; we're waiting on a word-sized monotonic counter interface > from hypervisors in the future. When we have the latter, then we can > start talking about mmapable things. Your use case would probably be > served by exposing that 16-byte unique value (hashed with some constant > for safety I suppose), but I'm hesitant to start going down that route > all at once, especially if we're to have a more useful counter in the > future. I kind of muddled things a bit by conflating two issues. I'd like the hypervisor to provide a counter so that we can mmap it to userspace so that userspace programs can do word-sized comparisons on mmap'd counters, avoiding the race that currently exists from relying on the async ACPI notification, which arrives after the system is already up and running. That's one thing, but not what we're talking about here with the MAC addresses. The point over here is that neither the guest *nor* the hypervisor can maintain a counter that actually represents something unique. A.1 and A.2 will both ++counter to the same value in the example above. The guest can't do it (neither in systemd nor in the kernel), because it will always start with the same counter value of A and ++ it to the same next value. The hypervisor can't do it either, because snapshots can be shipped around to different computers that aren't coordinated. So, put that way, the counter thing that I'd like wouldn't be for having a unique snapshot ID, but just as a mmap-able way of learning when a snapshot forks. It wouldn't be more useful than that. If you want a unique ID, we have two options for that: the first is exposing the vmgenid 16 byte value to userspace (which I don't want to do). The second is just calling getrandom() after you get a poll() notification, and that'll be guaranteed to be unique to that VM because of the vmgenid driver in 5.18. This last suggestion is thus what you should do for your MAC addresses. Jason
