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

phabricator-migrator · February 19, 2024, 5:42pm

Information

ID: 727
PHID: PHID-TASK-reh3qoq6kwlunl2dzimm
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal

Description

solve the low entropy issue in Xen VMs
look into kvm virtio-rng
implement something similar into Xen
submit the patch to the original Xenproject.org 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:

github.com/QubesOS/qubes-issues

Improve entropy collection in VMs

opened 04:36PM - 08 Mar 15 UTC

closed 09:39PM - 23 Mar 22 UTC

marmarek

T: enhancement C: other P: major cryptography ux

**Reported by joanna on 15 Nov 2012 19:03 UTC** While this is only my feeling, I… suspect that the entropy collection daemon in our VMs needs some improvements.. This is because of the limited interaction with the physical world of each VM (e.g. mouse events go via vchan instead of via kernel module in a VM). This can be easily noticed when one tries to generate a new GPG key in a VM -- the gpg would complain about inadequate entropy that is available and will hang until more is produced. One can produce more entropy via various disk activities (e.g. grep through the filesystem), however this: 1) Isn't very convenient 2) It's questionable whether such entropy is of "first-class freshness", or is it somehow inferior to the entropy that could be collected with the help of mouse movements, etc.? It would probably be desirable to create some entropy producing device that would run in each of the VMs, and to feed this device from Dom0 or other domains exposed to physical hardware (netvm, usbvm?). One should be careful, however, not to distribute the same "entropy bits" to more than one domain, as this would likely compromise domain isolation. Migrated-From: https://wiki.qubes-os.org/ticket/673

Comments

HulaHoop

2018-05-18 13:20:30 UTC

Patrick

2018-05-22 02:32:41 UTC

HulaHoop

2018-05-30 03:52:07 UTC

Patrick

2018-05-30 08:28:56 UTC

HulaHoop

2018-07-31 02:23:37 UTC

Patrick

2018-07-31 04:38:39 UTC

HulaHoop

2018-08-02 03:33:08 UTC

HulaHoop

2018-08-03 03:34:16 UTC

HulaHoop

2018-08-03 03:53:16 UTC

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.

Google Workspace Updates: New community features for Google Chat and an update on Currents

+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

2018-08-03 04:11:34 UTC

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] Adding CPU randomness to the entropy pool [LWN.net]

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

Patrick

2018-08-03 09:21:27 UTC