You can probably use virtio-rng since Qubes now runs on HVM mode and uses QEMU

Asked. Unfortunately not so.

https://github.com/QubesOS/qubes-issues/issues/673#issuecomment-390391346

Perhaps Qubes guys can have the entropybroker package communicate over the qrexec protocol to seed entropy from a reliable source like Dom0 to the other domains.

https://packages.debian.org/sid/utils/entropybroker

That's technically too late during boot process. See ticket discussion
above.

jitterentropy-rng should solve this and is a mainline Linux solution that works the same way haveged does. Please see: https://phabricator.whonix.org/T817

jitterentropy-rng should solve this

I am not sure about that. Addressed here:
https://github.com/QubesOS/qubes-issues/issues/673#issuecomment-409091212

T817 seems like a good idea anyhow.

I think its worth asking the hypervisor devs if this applies for the platforms we care about.

Done. Asked about Xen too but they may not be familiar with its innards. You may want to contact the Xen devs directly using my message as a template.

https://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg00368.html

An interesting implementation to work around early boot entropy scarcity with havegedis to include it in the initrd. May be hackish but could be easier for Marmarek than writing something at the EFI level.

https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/K22yyHRc6hn

+Dustin Kirkland Sorry for not being entirely clear. I don't meant to have haveged running as daemon all the time. But just use haveged --run 1024, which will give you 1MB of random data gathered by the haveg algorithm in a file called sample. THIS file you then use as a last resort to seed the random pool. Wouldn't that be a much nicer option :)? Haveged would even be small enough to embed into the initrd with only 115kB and no library dependencies beside libc (eg. to guarantee that "normal" user space is never executed with a bad seeded random pool).

Playing devil's advocate here: Ted Ts'o [0] expresses strong skepticism about the efficacy of RNGs that rely on CPU jitter. summary: CPU jitter may not be random as thought to someone who designed the CPU cache and know how its internals "tick" [1]. So while these RNGs may not harm, another solution for RNG-less platforms may be a good idea.

[0] He's the main developer behind Linux's RNG and staunchly resisted relying only on Intel's RDRAND. His opinions carry weight with good reason.

[1] https://lwn.net/Articles/586427/

It may be that there is some very complex state which is hidden inside the the CPU execution pipeline, the L1 cache, etc., etc. But just because *you* can't figure it out, and just because *I* can't figure it out doesn't mean that it is ipso facto something which a really bright NSA analyst working in Fort Meade can't figure out. (Or heck, a really clever Intel engineer who has full visibility into the internal design of an Intel CPU....)

In T727#16540, @HulaHoop wrote:

Done. Asked about Xen too but they may not be familiar with its innards. You may want to contact the Xen devs directly using my message as a template.

https://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg00368.html

ask Xen developers about Efficacy of jitterentropy RNG in Xen:
https://github.com/QubesOS/qubes-issues/issues/4174