Hi Greg, On Wed, Mar 2, 2022 at 9:53 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > It seems crazy that the "we just were spawned as a new vm" notifier is > based in the random driver, but sure, put it here for now! :) I was thinking you might say this. I see it both ways, but I think I'm more inclined to doing it this way, at least for now. Here's how it breaks down: VM forking is usually an okay thing to do because computers are deterministic. Usually. Where is there non-determinism in a place that it matters? The RNG is supposed to be "the" place of non-determinism. If anything is going to happen in response to a VM fork, it's going to necessarily be _after_ the RNG becomes sufficiently non-deterministic again, and so it's the RNG who announces, "hey I'm safe to use again, and please read from me again if you're doing non-misuse resistant crypto." It's the proper place to announce that. On the other hand, I think you could argue that really this should come from vmgenid itself, with the caveat that the notifier is called after add_vmfork_randomness is called. For now that would exist in vmgenid.o itself, and then if we ever have multiple drivers notifying, some shared infrastructure could be made. Except vmgenid.o might be vmgenid.ko, and then the whole problem gets kind of annoying and maybe we actually want that shared infrastructure _now_ instead. And now we find ourselves complicating everything with additional Kbuild symbols and header files and stubs. It just seems like the road of more pain. Anyway, even if we go with the first solution -- keeping it in random.o -- now, I wouldn't be opposed to revisiting that decision later if the landscape becomes more complex. Luckily this is just the kernel side of things and not userspace, so we can easily change things down the road. Jason
