Yes, modulo the fact that you want to update the CSPRNG with new entropy continuously to re-key it. Not to improve the cryptographic strength of the output or (for God's sake) to avoid "depletion", but to create forward secrecy. For instance: if the interval between reseedings is short enough, because updates are super cheap, you can make your RNG state churn too fast to be a useful target for something like Meltdown.
How does reseeding the CSPRNG create forward secrecy? I thought that if someone lifts your CSPRNG internal state (after it's been seeded and the seed tossed), they wouldn't be able to play it backwards to get previous output you've used as session keys or whatever.
I'm abusing the term, I know. But the idea is simple, right? Even a minuscule update to the kernel entropy pool makes a previously compromised state unusable. So you don't want your CSPRNG to just be a bit generator, like HMAC or CTR.
(Zvi Gutterman refers to the property I'm talking about as "backwards security", so my abuse of the term is particularly egregious).
Hah, I was really asking what you meant, not trying to chide you about about terminology. Makes sense, thanks.
Yes, but you don't need some dedicated source of high-bandwith random noise for that, using sources that already exist in essentially any system is almost certainly sufficient.
Somewhat philosophical corollary to that is that when you have hash function that is secure enough for your application you can just build CSPRNG from it and use small (eg. 128 or 256 bit) seed and you have no need for hardware RNG.