[avsm]

We're putting together a front/backend ring (rndfront/rndback) that will proxy entropy from dom0 directly into the guest. It'll take some time for this to percolate into the public cloud, so we'll need to do what Linux does in the meanwhile (harvest entropy from interrupt timings, attempt RDRAND, and so on).

The ENTROPY module type supports this sort of callback in 1.2.0: https://github.com/mirage/mirage/blob/master/types/V1.mli#L7...

(If you're interested in contributing, the entropy harvesting is in sore need of more eyes and help!)

[rwmj]

/me grumbles about virtio-rng and reinventing ABIs ...

[avsm]

Dave Scott's added support for a low-bandwidth channel into XL with the intention of reusing virtio-rng (and virtio-serial and friends). http://lists.xen.org/archives/html/xen-devel/2014-06/msg0293...

On the other hand, I disagree that we're reinventing an ABI given that:

1) virtio isn't the supported PV interface in Xen -- rndfront/back follows the same design principles as net/blk/fb/usb/pci/console etc.

2) The Xen shared-ring interface is older than virtio, and much simpler for pure PV guests such as Mirage (no PCI emulation to worry about). I do wonder what happened to that GSoC project from a few years to add virtio support to Xen though...I don't think any patches ever appeared.

[djs55]

s/added/currently trying to add/ :-)

For HVM guests I hope that virtio-rng would work as-is (if it could be turned on via the control path). That's definitely worth a look.

For PV guests like Mirage I'm currently plumbing through a Xen PV analogue of virtio-serial by hijacking^Wextending the existing PV console support. Since the backend for that is in qemu already it might be possible to hook up the entropy source (with all the rate limiting etc). I think the trick would be to get the guest to recognise the frontend for what it is -- I imagine the virtio-rng device in the guest presents itself as a magic hardware PCI device and 'just works'.