I thought that this patch e-mail had a nice explanation the entropy starvation issues that some people have been dealing with during boot.
Someone correct me if I’m wrong but it seems that in the absence of a hardware RNG, getrandom() can never be expected to work well. Collecting randomness based on interrupts is never guaranteed to unblock in any sort of reasonable time. Also it’s just a software heuristic that may not even meet the application’s criteria for randomness. Soap box here, but IMO ideally getrandom() should return EINVAL simply in the absence of a reliable hardware RNG and user-space can then take that as a signal to employ their own heuristics.
I believe you can employ two tricks to achieve sufficient entropy in the situation where you do not have a hardware RNG:
I think in a case where user-space seeded the kernel with randomness like that, I would support that also being a situation where getrandom() didn’t return EINVAL. At the same time, it may not even be necessary for the kernel to be involved unless it needed randomness itself (which I guess it often does).
I hit this problem with a custom GCE image, for whatever reason they sometimes gave me a VM without rng. I had to send some extra randomness encrypted with the boot metadata.
I encountered this issue when Qt switched to using getrandom() by default. A simple upgrade to a newer version of Qt, and suddenly this small embedded device would hang on boot. It turned out that Qt’s text streaming file IO operators were using QHash (Qt’s hash table) under the hood, which needs some random data to initialize itself.
The decisions (Using their own hash table internally, QHash using a secure algorithm, defaulting to a proper source of random data) make some sense, but it struck me as slightly absurd that as a result it needed a good source of random data to be able to read a text file.