Problems emerge for a unified /dev/*random

I remember having discussed this problem with Jason a few years ago, saying that until we instrument boot loaders to feed entropy on embedded devices, it's a dead end. Indeed, the only source of entropy you can have on small devices are:
- pre-init device contents (uninitialized RAM usually contains noise, except in VMs);
output GPIOs may also read noise before they're configured as outputs. UARTs
often read a first crappy byte. Many chips also include a "reset cause" register
that indicates power-on, reset, exception, etc

- device reset timings (slow devices such as UARTs do not always take an integral
number of cycles to reset; RTC's second transition also solely depends on when
the device was booted, relative to the current second.

- the device's configuration: very often you'll find a MAC or some device-specific
WiFi calibration data stored in a special area on the flash, that may differ from
device to device. When running in a VM, some arguments may come from other
means.

- other external persistent info (e.g. any RTC time value that varies between boots)

But often all these data are lost after the boot loader finishes initialization and transfers execution to the kernel. We'll *need* to standardize a solution for this, that boot loaders will have to use for future kernels if we want to improve the situation for such embedded devices. Otherwise they're too deterministic. I do remember that the SSH key I used to have on my old NSLU2 existed on at least 89 other devices connected to the net... This definitely shows that without early entropy there's little hope to collect more later and whatever we'll try to do can result in frustration. And while VMs are terrible for this, at least they can benefit from entropy being spoon-fed at boot by the hypervisor.