Re: [MirageOS-devel] vchan hackers wanted for mirage-entropy

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Hi Nicolas,

On 11/21/2014 08:27, Nicolas Ojeda Bar wrote:
> After discussion, it seems that the vchan/xenstore libraries are
> not up to where they should be to make this work.

That's unfortunate to hear. Didn't Dave suggest a solution:

>> In the meantime I think you could solve the problem in a more
>> (Xen-)traditional fashion by creating a privileged daemon which
>> runs in dom0 and acts like the toolstack. It would
>> 
>> * watch for the arrival of new domains via the @introduceDomain
>> watch * create a vchan connection to each one directly

> In the very short term, it was suggested to generate a seed from
> /dev/urandom at compile time and then use that to seed the entropy
> generator.

While this is better than the current implementation (which uses
OCaml's Random, which on Xen is seeded very deterministic if I
understand that code correctly
https://github.com/ocaml/ocaml/blob/638a953bcf61678307fa5d0e1a969aaaf3f1ab20/byterun/sys.c#L364),
it is too easy to get it wrong (running the same unikernel image
several times with the same seed) that I don't feel comfortable to
ship mirage(-tls) with that.

>> Itâs also worth having a look at the qemu virtio-rng driver. Itâs
>> got some logic in there for rate-limiting â it would be good to 
>> understand whether we need that too.

My understanding is that we're concerned about getting _entropy_ in
the virtual machines, rather than random (what virtio_rng is about).
The random is generated in each VM using Fortuna - The amount of
entropy fed into Fortuna is (on UNIX, using mirage-entropy-unix) 16
byte every 10 minutes...


Hannes

> Yesterday night I pushed PRs to `mirage` 
> (https://github.com/mirage/mirage/pull/323) and `mirage-entropy` 
> (https://github.com/mirage/mirage-entropy/pull/7) to implement
> this idea. It is hacky (esp. the modifications to the configure
> script), but it should work.  Any comments welcome.
> 
> Cheers, Nicolas
> 
> On Thu, Nov 20, 2014 at 7:29 PM, Nicolas Ojeda Bar 
> <no263@xxxxxxxxxxxxxxx> wrote:
>> FYI
>> 
>> ---------- Forwarded message ---------- From: Dave Scott
>> <Dave.Scott@xxxxxxxxxx> Date: Thu, Nov 20, 2014 at 2:55 PM 
>> Subject: Re: ocaml-xenstore questions To: Nicolas Ojeda Bar
>> <no263@xxxxxxxxxxxxxxx>
>> 
>> 
>> Hi,
>> 
>>> On 20 Nov 2014, at 14:29, Nicolas Ojeda Bar
>>> <no263@xxxxxxxxxxxxxxx> wrote:
>>> 
>>> Dear Dave,
>>> 
>>> I have some questions and Anil suggested I emailed you about
>>> them.
>>> 
>>> A little explanation:
>>> 
>>> I am trying to use ocaml-xenstore to build a server in dom0
>>> that will serve entropy from /dev/urandom to any unikernel that
>>> wants it via vchans.  I can already send the data using
>>> ocaml-vchan (manually setting the domid of the client) and now
>>> I want to use the xenstore to negotiate the client connections
>>> so that we do not need to enter the domid manually.  There is
>>> some code in conduit that seems to be what we need
>>> (Mirage_xenstore).
>> 
>> I think the conduit negotiation code works well enough as a
>> prototype, but itâs not secure enough for proper use because of
>> the limitations of the xenstore access control system.
>> 
>> In a Xen system the âtoolstackâ (xend, xl, xapi etc) uses its 
>> privileged access to create backend and frontend directories,
>> setting the permissions and introducing the domains to each
>> other. In the conduit prototype we made it peer to peer (no
>> toolstack) but this meant we had to grant the equivalent to
>> âchmod a+rwxâ to a xenstore treeâ this means that anyone can
>> interfere with anyone elseâs connections.
>> 
>> https://github.com/mirage/ocaml-vchan/blob/master/lib_test/mirage/init-xenstore.sh#L6
>>
>>
>> 
The xenstore protocol (of which the access control stuff is part)
>> evolves very slowly because itâs a core part of the system. I
>> think we should explore changing that but it will take a while.
>> In the meantime I think you could solve the problem in a more
>> (Xen-)traditional fashion by creating a privileged daemon which
>> runs in dom0 and acts like the toolstack. It would
>> 
>> * watch for the arrival of new domains via the @introduceDomain
>> watch * create a vchan connection to each one directly
>> 
>>> 
>>> Questions:
>>> 
>>> - The latest ocaml-xenstore in opam is 1.2.5.  It seems to be
>>> quite out of date.  I pinned the current github repo but then
>>> mirage-xen stopped compiling.  Is this supposed to happen ? Do
>>> you know how to set things up to use the ocaml-xenstore trunk
>>> ?
>> 
>> The trunk contains interface changes which are still being
>> developed. When the interface changes are finished Iâll go around
>> and update all the clients (block driver, network driver, console
>> driver etc). I recommend avoiding this and sticking with 1.2.5
>> :-)
>> 
>> 
>>> - Mirage_xenstore in ocaml-conduit uses the OS.Xs module (a
>>> Xenstore client).  This module will not work in dom0 because
>>> the Unix backend of OS does not have a Xs submodule.  Anil
>>> thought that there was a unix implementation of a Xenstore
>>> client that could be used instead. Do you happen to know where
>>> to look for this ?
>> 
>> Have a look at the mirage console code:
>> 
>> https://github.com/mirage/mirage-console/blob/master/cli/main.ml
>> 
>> In particular this is a CLI which runs in dom0 and makes console 
>> (rather than vchan) connections to other domains.
>> 
>> Watching xenstore for new domains is such a common requirement
>> that Iâd like to extend the xenstore API to include it. For now
>> thereâs some code here which can do it:
>> 
>> https://github.com/xapi-project/xenops/blob/master/src/xenstore_watch.ml#L48
>>
>>
>>>
>> 
I believe that you will be by the Computer Lab later today, so I may
>>> pester you with more questions.
>>> 
>>> Thank you very much!
>> 
>> Itâs also worth having a look at the qemu virtio-rng driver. Itâs
>> got some logic in there for rate-limiting â it would be good to
>> understand whether we need that too.
>> 
>> Good luck! :-)
>> 
>> Cheers, Dave
>> 
>> 
>>> 
>>> Best wishes, Nicolas
>> 
>> On Thu, Nov 20, 2014 at 11:36 AM, Anil Madhavapeddy
>> <anil@xxxxxxxxxx> wrote:
>>> On 20 Nov 2014, at 09:57, Nick Hardiman
>>> <nick@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>> 
>>> 
>>> On 20 Nov 2014, at 05:02, david <unitedbiscuits@xxxxxxxxx>
>>> wrote:
>>> 
>>> 
>>> i think it would be nice to assemble a blog post or set of
>>> instructions or something that describe the various ways of
>>> running xen in a development environment for mirage. (and
>>> deployment environments for that matter.)
>>> 
>>> 
>>> Speaking as an amateur idiot, I'd say there are missing steps
>>> for a Xen install that should be come before
>>> http://openmirage.org/wiki/install. I look forward to following
>>> the instructions.
>>> 
>>> 
>>> Agreed. It's become easier in recent years with the Ubuntu
>>> packaging improving, but it's by no means well documented.
>>> 
>>> I just rebooted my VMWare Fusion Ubuntu setup with Xen and now
>>> the virtual graphics driver bombs out and hangs for some
>>> reason.  Ho hum...over to Virtualbox for me too I guess.
>>> 
>>> Magnus: if you kick off the blog post about your setup, we can
>>> cut-and-paste that into a more centralised version to benefit
>>> other folk as well.  Nik's excellent work on the Vagrant setup
>>> should also be of use -- has anyone tried it? (it's at
>>> https://github.com/mirage/mirage-vagrant-vms)
>>> 
>>> -anil
>>> 
>>> 
>>> _______________________________________________ MirageOS-devel
>>> mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx 
>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>
>>
>>
>>> 
On Wed, Nov 19, 2014 at 5:24 PM, Nicolas Ojeda Bar
>> <no263@xxxxxxxxxxxxxxx> wrote:
>>> Yep, I got one so I should be set.
>>> 
>>> Cheers, Nicolas
>>> 
>>> On Wednesday, November 19, 2014, Anil Madhavapeddy
>>> <anil@xxxxxxxxxx> wrote:
>>>> 
>>>> Great!  One minor annoyance with vchan is that it does
>>>> require a Xen machine to establish communications. If you
>>>> don't have a Xen host, a Cubieboard is the easiest way to get
>>>> started in the short term, or a Virtualbox setup.  I believe
>>>> that Magnus is writing down the instructions for his
>>>> Virtualbox setup at the moment...
>>>> 
>>>> -anil
>>>> 
>>>> On 19 Nov 2014, at 17:19, Nicolas Ojeda Bar
>>>> <no263@xxxxxxxxxxxxxxx> wrote:
>>>> 
>>>> Hi Anil,
>>>> 
>>>> I can try my hand at this; I need a break and wouldn't mind
>>>> doing this while I write the Ipv6 blog post.
>>>> 
>>>> Cheers, Nicolas
>>>> 
>>>> On Wednesday, November 19, 2014, Anil Madhavapeddy
>>>> <anil@xxxxxxxxxx> wrote:
>>>>> 
>>>>> Anyone got time for this?  Writing the dom0 proxy is pretty
>>>>> much a hello-world use of the vchan bindings.  In theory,
>>>>> this should work using the OCaml-conduit Vchan_lwt_unix
>>>>> mode, but in practise noone has tried it yet.
>>>>> 
>>>>> From the client side, it just needs a vchan call to read a
>>>>> certain number of bytes and block if dom0 isn't supplying
>>>>> it with enough.
>>>>> 
>>>>> -anil
>>>>> 
>>>>>> On 19 Nov 2014, at 16:52, Hannes Mehnert
>>>>>> <hannes@xxxxxxxxxxx> wrote:
>>>>>> 
> Hello,
> 
> in order to move OCaml-TLS onto Xen, there is one bit missing which
> I neither know in detail nor have the time to deal with. How to get
> entropy into a Mirage unikernel. The startup sequence is rather
> deterministic, and we don't want to require a RW object store to
> keep the seed (best practises in the UNIX world).
> 
> Instead we would like to proxy /dev/urandom from dom0 into the 
> unikernel to seed our random number generator.
> 
> The interface is already there: 
> https://github.com/mirage/mirage/blob/master/types/V1.mli#L75 There
> is also an implementation for Xen, but this uses very weak 
> entropy: https://github.com/mirage/mirage-entropy/tree/master/xen
> 
> 
> Some related work I found was virtio-rng 
> (https://fedoraproject.org/wiki/Features/Virtio_RNG) which is
> supposed to work on Xen as well 
> (http://wiki.xen.org/wiki/Virtio_On_Xen) -- but this might very
> likely be overengineered for our purposes.
> 
> We (well, David) already have a state of the art random number 
> generator implemented (Fortuna, design by Schneier + Ferguson)
> here: 
> https://github.com/mirleft/ocaml-nocrypto/blob/master/src/fortuna.mli
>
> 
> 
> If someone could give that a try, it'd speed up to get mirage-tls
> into a usable state.
> 
> 
> Thanks,
> 
> Hannes
>>>>>> 
>>>>>> _______________________________________________ 
>>>>>> MirageOS-devel mailing list 
>>>>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx 
>>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 
_______________________________________________
>>>>> MirageOS-devel mailing list 
>>>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx 
>>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>>
>>>>
>>>>> 
_______________________________________________
>>>> MirageOS-devel mailing list 
>>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx 
>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>>
>>>>
>>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCQAGBQJUbxRIAAoJELyJZYjffCju904QAJh+iM2tn50s85cr+yufvyQj
U+NpY2ZbuJ/0TY3p3uLCZpT0BI9GO4DDPTlAtS5sRIA6YRMMIhZ1YF8itX8ivN5Q
nKmumEdT90Ocn43VQ0U1RdtlvMkFrvnP+b1Y2fniYrCml0EGMwUgGl+SqEbhn71z
6+Mk8/ClVff0eLLAP7j3g8vNOhuOGXnksgfqrkqinNz0Hu1CHQ3+pNWB0vwV1nQZ
56pP7r+F/4FNL5MoJCj6r/qv7lsAl5rVqkD6xyQ/J0OPJzlpVqy9lF/IXhLyKJ2v
ZEQyP3qyRCE6mP0yYm+VLjX7ogqsN+8obEYrB9Oj3+9gLXr2hN/B1Vtp3ajNJ2FX
KXcluPC1JmoAq3XYPKeqBYCJNljkIYE6vDRoFMdh9kzeMLyD5ynZ4tzCjKRLzWU4
LMBR1gv+WfsjaJnIjTTj0sp9qp8tP2V+kb5Bn3EBZLBWunztnCdOaHq+YRzeS2XZ
uT4xUSBPo41SlEAMw2nAqDCDF/G06URxHVCUyunMzYebubLWzORukKvhi1KoonsV
kOvKiuohSDpFt1nSpuek3H83hnkyphA0UwsTbwCz6SC6dpkT1ekyp8QynCk32eU8
ej1Zbi5tRSEjJGa+WQJslOhJJtzP9SOiJgxfjXnijTNwaZx4OjWQzbbO+PSz8RFm
rAN438clB73e1qhFLxcX
=o4/c
-----END PGP SIGNATURE-----

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel