Well, not all Linux hardware provides sufficient entropy on first boot, such as solid-state embedded hardware or virtual machines. The CSPRNG will happily provide random bits regardless of initial seeding or not. Flip a coin 512 times, record the results, and &quot;echo tththhhhthh... &gt; &#x2F;dev&#x2F;random&quot;. Most people don&#x27;t want to do this, so hardware RNGs simplify this.<p>If only the Linux kernel used as entropy everything that was available to it. That&#x27;s the pitch of haveged(8) I think. There are significantly more timing events the kernel could use for input entropy that it&#x27;s not. It would be great to see these timing events land in random.c, but they&#x27;re not there.<p>Lastly, slightly off-topic, but the Linux CSPRNG is poorly designed. In reality, while preimage SHA-1 might still have a sufficient security margin, it suffers from poor performance due to ad-hoc design. Instead, using AES-128 CTR_DRBG with AES-NI would give the kernel CSPRNG a much needed performance boost, provide backtracking resistence, and remain secure. Current testing shows it could improve from 20 MiBps to 2 GiBps.