Re:Fixing Getrandom()
by denton-scratch on Wednesday October 02, 2019 @08:43AM
(#21135737)
VirtIO-RNG has not been officially accepted into Xen (it seems to be easier to incorporate into a PV DOMU).
If you have RDRAND hardware, you could (I suppose) pipe it's output from DOM0 into an encrypted root terminal session on DOMU, and feed that into the pool.
I personally don't want to rely on RDRAND. Unlike a tampered ADD instruction, a tampered RDRAND instruction would appear to be undetectable, even in principle. I wish Intel had given me the raw bits from their DRBG, instead of providing only the whitened stream. Or hell, give me both - but not just an opaque stream.
Randomness in VMs isn't a problem. If VM hypervisors aren't providing VirtIO-RNG, it's still just a quick fix and reboot away. The quickest way to make sure all hypervisors and hosting providers enable VirtIO-RNG, or something similar, is for the kernel to being assuming, loudly, that strong entropy is available at boot time.
For embedded stuff SPI RNG chips and similar solutions have been available since forever, not to mention the on-chip sources on most modern ARM and x86 CPUs and SoCs.
If a product designer (e.g. embedded device) or solution provider (cloud hosting) chooses to put their trust in RDRAND alone, then that's their choice--Linux shouldn't be second guessing it, or at least allow such a choice to dictate the semantics of its APIs.