There is no such thing as being "starved for entropy", once you've hit whatever threshold you require for considering your RNG to be seeded in the first place.
If your PRNG state is is x bits, if you initialize it with less than x bits of entropy you are starved.
Since you cannot know how many bits of entropy getrandom() would give you and when it itself is reseeded with fresh entropy, you usually have your userspace PRNG sample getrandom() for some amount of time, after which it is considered initialized.
There is no magic. If entropy got injected in between getrandom() calls you get that entropy - it does not matter if the entropy is cryptographically scrambled and 'merged' into the kernel PRNG state.
All you have to do is 'merge'/'absorb' multiple getrandom() results over some time t into your userspace PRNG, with t big enough to allow for multiple reseeding events by the kernel. You are in effect getting samples of the new entries into the kernel entropy pool indirectly by doing this, sampling too frequently is wasteful however as you are just going to be sampling the kernel CSRPNG with the same entropy in its state most of the time.
Doing the above is actually the only way to properly seed your userspace CSPRNG if your userspace CSPRNG has a state larger than the kernel CSPRNG (kernel's is 512 bits I believe) otherwise you will be working with a 512 bits of entropy as an absolute maximum even if your CSPRNG is capable of holding more, at least until reseeding (both the kernel and the userspace PRNG).
Comments
There is no such thing as being "starved for entropy", once you've hit whatever threshold you require for considering your RNG to be seeded in the first place.
If your PRNG state is is x bits, if you initialize it with less than x bits of entropy you are starved.
Since you cannot know how many bits of entropy getrandom() would give you and when it itself is reseeded with fresh entropy, you usually have your userspace PRNG sample getrandom() for some amount of time, after which it is considered initialized.
Who is “you”? Calling getrandom() extra times to get extra bits on the hope that the result is magically better is entirely useless.
There is no magic. If entropy got injected in between getrandom() calls you get that entropy - it does not matter if the entropy is cryptographically scrambled and 'merged' into the kernel PRNG state.
All you have to do is 'merge'/'absorb' multiple getrandom() results over some time t into your userspace PRNG, with t big enough to allow for multiple reseeding events by the kernel. You are in effect getting samples of the new entries into the kernel entropy pool indirectly by doing this, sampling too frequently is wasteful however as you are just going to be sampling the kernel CSRPNG with the same entropy in its state most of the time.
Doing the above is actually the only way to properly seed your userspace CSPRNG if your userspace CSPRNG has a state larger than the kernel CSPRNG (kernel's is 512 bits I believe) otherwise you will be working with a 512 bits of entropy as an absolute maximum even if your CSPRNG is capable of holding more, at least until reseeding (both the kernel and the userspace PRNG).