See https://factorable.net/weakkeys12.extended.pdf, which includes some identifications of some of the responsible devices. (Two groups of researchers published independently on this issue at nearly the same time.)
The takeaway is: Linux's /dev/random and /dev/urandom interfaces are both broken, in the sense that neither is reliable for embedded developers during certain early boot conditions. Some of that was maybe worse in 2012 than today, but the fundamental interface properties have not changed.
Tl;dr: Use getrandom() instead of /dev/[u]random. Do not use GRND_RANDOM. Do not use GRND_NONBLOCK.
> Surprisingly, modern Linux systems no longer collect entropy from IRQ timings. The Linux kernel maintainers deprecated the use of this source in 2009 by removing the IRQF_SAMPLE_RANDOM flag, apparently to prevent events controlled or observable by an attacker from contributing to the entropy pools.
> Although mailing list discussions suggest the intent to replace it with new collection mech- anisms tailored to each interrupt-driven source [21], as of Linux 3.4.2 no such functions have been added to the ker- nel.
> The removal of IRQs as an entropy source has likely exacerbated RNG problems in headless and embedded devices, which often lack human input devices, disks, and multiple cores. If they do, the only source of entropy—if there are any at all—may be the time of boot.
It may have been inspired by arguments like https://blog.cr.yp.to/20140205-entropy.html (although that one was published five years later than the change we're talking about).
That would be rather misguided though. It's not like a device is going to know the exact time the interrupt handler routine would run, hash it, and go back "whoops, better not fire an interrupt yet because it won't be on the right tick!"
No. The fundamental problem — random blocks arbitrarily after seeding, and urandom does not block even before seeding — existed prior to the 2009 change.
For keys that are generated during early/first boot conditions, couldn't one wait until /proc/sys/kernel/random/entropy_avail is greater than 256 and then read from urandom? IIRC getrandom still isn't universally available on SoCs kernels.
I was 1/2 way through reading your comment and was thinking, "Yeah, but they can use the getrandom() that was ported from OpenBSD", but you obviously beat me to it. Take your upvote!
OpenBSD's interface is getentropy(), but yeah, basically the same idea! I believe Linux was the second actor and intentionally made getrandom() a superset of the getentropy interface (i.e., no EINTR below 256 bytes).
As a result, writing a getentropy() shim around getrandom is feasible; FreeBSD and Linux (glibc) have done so.
