http://manpages.ubuntu.com/manpages/trusty/man4/random.4.htm...
For example, an installation process using an .iso image could, after verifying the .iso, put a random seed inside the .iso (unpack-modify-pack) as a pre-configuration step. Like an extra preparation step after downloading. New installation = new pre-configuration step, to avoid seed reuse.
The previous would apply to VMs and containers and such.
For traditional embedded/IoT style devices, the step could be done at the factory when flashing the image. Or maybe there could be a small flash area with the seed as part of the initial flashing procedure.
I guess some forms of installation end up being "problematic" to handle (ro root filesystems maybe).
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.
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.
This seems eminently unfeasible for many applications, and it won't work at all for read-only filesystems as you've mentioned.
It's a speaking pattern meant to convey "we've got to do something about <x> and people don't like <y> (so it's gotta be <x>)". In reality there are almost always more <options> than the duality implies but at no point does the person ever actually want <y>.
In your example, the fact that the first option is self-evidently correct even in a vacuum, is something of a cue that the second option isn't meant to be taken as seriously.
In Tso's statement, it's not immediately clear to me which of the two options he prefers. In fact, his use of the phrase "get over it" leads me to think that is actually his preferred variant. To me, that phrasing means if not an outright trivial and unworthy concern, then at least one that only needs the passage of time. There doesn't seem to be any indication that he's using the phrase ironically or anything.
Of course it is always possible that I'm just misreading or misinterpreting it. But that is why the first half didn't, and still doesn't, seem relevant to me.
> we need to find some way to fix userspace's assumptions that they can always get high quality entropy in early boot, or we need to get over people's distrust of Intel and RDRAND
Though ts'o is also ignoring the third option — and the one used by openbsd — of storing an rng seed after boot (and on shutdown).
The very first boot does remain problematic if the image isn't seeded though.