PCs can and do include hardware support for entropy gathering, see RDSEED [1]
Linux is aware of RDSEED and uses it to provide additional randomness when available. You do need to trust the implementation to be free from backdoors and bugs - some CPUs are known to be buggy. [2]
Randomness seeding issues largely does not concern desktop PCs or smartphones (although you can easily catch early booting programs like systemd reading randomness before it has been fully seeded) [3].
It is a much bigger issue on either small embedded devices or VMs, both of which may have very few peripherals to gather entropy from. They can be provided randomness through dedicated hardware support, or from the host, and they probably should be, but that still leaves many real-world systems currently running Linux out in the cold. This is not just a theoretical problem, as has been shown by looking at indicators like RSA keys with colliding primes, which should never happen when generated with good RNG. [4]
You don't even need sensors. STMicroelectronics has a TRNG block [1] that "passes" NIST SP 800-22 statistical analysis [2]. I used quotes because the 800-22 is an analysis test suite and the notion of passing is based on your hypothesis parameters, but the suite itself is considered the de-facto analysis mechanism.
I don't follow where the confusion is coming from?
Agreed, but my example was for very low cost embedded systems where that makes sense like super cheap IoT sensors where every fraction of a cent is accounted for.
If your security threat profile has to account for actors with the resources to perform reverse engineering of your hardware, side channel analysis and RF injection, then we're already way out of the realm of low cost devices.
The embedded systems that GP is referring to generally don't have a full-stack OS; hardware access is performed by directly reading to/writing from registers.
Hmm good points, but you also ignore the power costs here - using oscillators, open pins as thermometers and rf antennas requires additional power draw, not to mention modifying these devices may be nearly impossible due to their embedded nature.
Even presuming you modify the hardware/firmware, the additional cycles to handle and process the sensor data mean additional power draw compared to normal operation (embedded devices may frequently power down to wake from some interrupt to save power, additionally not all instructions turn on the same number of transistors - floating point ops require more power than simple branch instructions) - something again that prohibits doing this easily.
So "without any added cost" is simply untrue.
The reality is that randomness is relatively expensive, whether via hardware or software. Phones have more sensors - they also have massively complex SoCs and large batteries, which still are drained often over the course of a single day. They also tend to cost 1k+ USD, at least for flagship models (prices go as low as 50$ these days, but this is more from economies of scale and resale value economics than because phone hardware/software is suddenly cheap to manufacture)
For KVM VMs, please use virtio-rng! If you have virtio (which most VMs do) then adding a virtio-rng virtual device costs nothing and gives the VM access to the host's entropy. systemd etc in the VM should then have no problem at all consuming as much entropy as it likes as early in the boot as it needs.
Could timing be used to seed a cpu? ie, not all cpus are built the same, and similarly for all powersupplies, could the two be used together to bootstrap seeding i.e. by measuring voltage or voltage differences?
Yes! I went to a talk given by a security researcher who proposed using the difference in clocks between north bridge and south bridge to generate randomness.
Linux is aware of RDSEED and uses it to provide additional randomness when available. You do need to trust the implementation to be free from backdoors and bugs - some CPUs are known to be buggy. [2]
Randomness seeding issues largely does not concern desktop PCs or smartphones (although you can easily catch early booting programs like systemd reading randomness before it has been fully seeded) [3].
It is a much bigger issue on either small embedded devices or VMs, both of which may have very few peripherals to gather entropy from. They can be provided randomness through dedicated hardware support, or from the host, and they probably should be, but that still leaves many real-world systems currently running Linux out in the cold. This is not just a theoretical problem, as has been shown by looking at indicators like RSA keys with colliding primes, which should never happen when generated with good RNG. [4]
[1] https://en.wikipedia.org/wiki/RDRAND
[2] https://github.com/systemd/systemd/issues/18184
[3] https://github.com/systemd/systemd/issues/4167
[4] https://freedom-to-tinker.com/2012/02/15/new-research-theres...