Hi Alex, Strangely your message never made it to me, and I had to pull this out of Lore after seeing Daniel's reply to it. I wonder what's up. On Thu, Feb 24, 2022 at 09:53:59AM +0100, Alexander Graf wrote: > The main problem with VMGenID is that it is inherently racy. There will > always be a (short) amount of time where the ACPI notification is not > processed, but the VM could use its RNG to for example establish TLS > connections. > > Hence we as the next step proposed a multi-stage quiesce/resume > mechanism where the system is aware that it is going into suspend - can > block network connections for example - and only returns to a fully > functional state after an unquiesce phase: > > https://github.com/systemd/systemd/issues/20222 > > Looking at the issue again, it seems like we completely missed to follow > up with a PR to implement that functionality :(. > > What exact use case do you have in mind for the RNG/VMGenID update? Can > you think of situations where the race is not an actual concern? No, I think the race is something that remains a problem for the situations I care about. There are simpler ways of fixing that -- just expose a single incrementing integer so that it can be checked every time the RNG does something, without being expensive, via the same mechanism -- and then you don't need any complexity. But anyway, that doesn't exist right now, so this series tries to implement something for what does exist and is already supported by multiple hypervisors. I'd suggest sending a proposal for an improved mechanism as part of a different thread, and pull the various parties into that, and we can make something good for the future. I'm happy to implement whatever the virtual hardware exposes. Jason
