Page MenuHomePhabricator

solve the Xen entropy scarcity problem / implement something like virtio-rng into Xen upstream
Open, HighPublic


  • solve the low entropy issue in Xen VMs
  • look into kvm virtio-rng
  • implement something similar into Xen
  • submit the patch to the original developers so it passes their quality check and they merge it upstream

(No - haveged is not a solution. It starts much too late. We need a real /dev/random inside all VMs. So something like virtio-rng.)

(Related or even duplicate: T31 - but this ticket has a much clearer description.)

Qubes upstream ticket Improve entropy collection in VMs:



Event Timeline

Patrick created this task.Nov 4 2017, 3:43 PM
Patrick updated the task description. (Show Details)Nov 4 2017, 3:44 PM
Patrick added a project: Qubes.
Patrick added a subscriber: marmarek.

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

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.

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

jitterentropy-rng should solve this and is a mainline Linux solution that works the same way haveged does. Please see:

jitterentropy-rng should solve this

I am not sure about that. Addressed here:

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.

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.

+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).

HulaHoop added a comment.EditedAug 3 2018, 6:10 AM

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.


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....)

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.

ask Xen developers about Efficacy of jitterentropy RNG in Xen:

Patrick updated the task description. (Show Details)Aug 3 2018, 11:22 AM
Patrick added a project: security.