The work on Mirage is very interesting. If I understand it correctly, it may be possible to run a Xen domain with a Linux application server, and with a TLS reverse proxy in front using another Xen domain (in the form of a unikernel).
This would be fantastic and does not change a lot how you run your application, except that you get hardened crypto for free.
That's assuming that ocaml-tls has no "high level" bugs (not memory corruption related) of course, but I'm quite sure that it is way easier to review than existing TLS implementations.
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).
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.
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'.
It concerns us too. Right now the entropy in Xen domains is weak, but we are working with the rest of the team to feed some actual environmental noise to keep Fortuna well-fed.
You can also run the library on Unix, of course, and there the RNG is periodically seeded from /dev/urandom.
This would be fantastic and does not change a lot how you run your application, except that you get hardened crypto for free.
That's assuming that ocaml-tls has no "high level" bugs (not memory corruption related) of course, but I'm quite sure that it is way easier to review than existing TLS implementations.