Once the generator had been seeded (once), sure, read from urandom and don't worry.
The main issue is trying to read from it at boot time
> If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Once /dev/random is available, don't use /dev/random, use /dev/urandom. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. This is essentially what getrandom(2) does.
This is outlined here as well: https://paragonie.com/blog/2016/05/how-generate-secure-rando...
This is what randombytes_buf() does in libsodium on older Linux kernels.
This is actually the best of both worlds: Although /dev/urandom on Linux will happily give you predictable values if you try to read from it before the RNG has been seeded on first boot, once /dev/random is "ready" to be read from once, you know that the entropy pool powering /dev/urandom has been seeded. And then you can guarantee that /dev/urandom is secure and nonblocking henceforth.
If you can't just use getrandom(2), do the "poll /dev/random, then read /dev/urandom" dance and even the fearmonger's favorite issue to cite becomes a non-issue.
1. /proc/sys/kernel/random/read_wakeup_threshold is 64 by default [1,2], but the kernel only considers the pool initialized with >128 bits [3]. So in an early userspace you're likely to be reading from an uninitialized /dev/urandom after waking up from poll if you're not also checking the entropy count to be >128.
2. /dev/random could be a symlink to /dev/urandom, so the call to poll would return as soon as possible.
3. The system could only be providing /dev/urandom.
So if you're going to have to check the entropy count anyway, a less convoluted approach would be to repeatedly retrieve it via the RNDGETENTCNT ioctl [1] on a /dev/urandom file descriptor and sleeping while it hasn't reached >128 bits yet.
Don't take my word for the feasibility of this fallback method as I'm not a cryptographer or implementer of cryptographic interfaces. Instead, consider BoringSSL (Adam Langley et al.) that does almost the same in its /dev/urandom fallback. [4]
[1]: http://man7.org/linux/man-pages/man4/random.4.html
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[4]: https://boringssl.googlesource.com/boringssl/+/refs/heads/ma...
Entropy running low is not an actual problem. AES-CTR doesn't "run out of key".
If your OS's "entropy estimator" is producing small numbers and your userspace applications are using /dev/random, yes, that will degrade your performance. That's the actual problem.
The solution is for the developers of your software to stop using /dev/random, wholesale.
Saying that the actual problem is "entropy running low" is like saying "water is flammable". That might be true in extreme cases, but isn't in the general case.