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

[david <unitedbiscuits@xxxxxxxxx>]

On Fri, Nov 21, 2014 at 8:14 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 21 Nov 2014, at 18:45, david <unitedbiscuits@xxxxxxxxx> wrote:
>>
>> On Fri, Nov 21, 2014 at 11:39 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> On 21 Nov 2014, at 10:30, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>>>>
>>>> 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.
>>
>> This solution is easily much more dangerous; while `Random.self_init`
>> is as unpredictable as `gettimeofday`, and it is not hard to recover
>> the future of the random stream, fully *repeating* the stream will
>> completely compromise at least several algorithms I'm aware of. This
>> is because nonces require the guarantee of non-repetition (up to
>> astronomically small p), but not unpredictability. I tried to argue as
>> much in [1].
>
> It's only more dangerous in isolation.  This solution, *in combination*
> with other sources such as the current time, should be how we do entropy.
> A similar analogy is random.seed in the OpenBSD boot loader:  a per host
> (or in this case, VM) source of entropy is still useful since it's
> unique per-host, despite being repeated across reboots.  The other sources
> take care of the other dimension.

This is true. The more I think about the ARM case, with no RDRAND and
with timers of potentially really bad granularity, the more I'm afraid
the self-maintaining story will break down.

Still, if unleashed unto the world in isolation, a
one-time-pad-that-isn't could be really disastrous, on its own.

>>> Another alternative we could do in the short-term is just to pass
>>> the 16 bytes-every-10-minutes directly via Xenstore instead of a
>>> full-blown Vchan.  This would just require a daemon in dom0 to be
>>> run that does this.  The paper above also notes that the Xenstore
>>> hooks are useful to reinject fresh entropy upon suspend/resume,
>>> which couldn't be done easily in a pure vchan solution.
>>
>> As Hannes pointed out, but maybe bears repeating: what mirage-entropy
>> is supposed to provide is not high-throughput. It serves to
>> periodically send small, relatively unpredictable packets. TLS itself
>> uses these to make the actual random stream.
>>
>> Even if we had a high-throughput vchan sending GBs of entropy, we
>> would not read from it too eagerly. Entropy mixing and conversion into
>> the random stream is internal to TLS, and only small inputs are
>> required for everything to work nicely.
>>
>> So for a quick fix, just sending a few bytes from dom0 rng every few
>> minutes is quite enough, in situations where we have control over
>> dom0. That entropy is high-quality, so it's ok to re-add it
>> infrequently. We could use any low-speed, high-latency channel for
>> this. We could write randomly named files on NFS and mix in the result
>> of `readdir`.
>>
>> Plus, all the long term-solutions still contain the above as the
>> method of quickly bootstrapping the rng before its internal entropy
>> gathering has had a chance to take over.
>>
>> So I believe the priority in the entropy saga should be *any* way to
>> dispatch a very small trickle of dom0 /dev/urandom to vms. With that,
>> we have our starting point.
>>
>
> Yes, but but let me reiterate that we *must* have a solution that
> also works without a dom0 entropy proxy.  It may be that binding
> RDRAND and scraping inter-event channel timings is the only answer, but
> we must be able to get entropy at least as strong as existing VMs
> do without dom0 assistance.

Yeah. I don't suppose we can just install entropy harvesting daemons
in EC2 or RackSpace dom0s.

> For that reason, I think we should still take a compile-time one-time
> pad as one of the entropy sources, just like OpenBSD mixes in a
> /etc/random.seed to help with start-of-day.

Do you think Lwt people would be open to a small change in
`Lwt_engine` API, if somebody sent them a patch?

It's perfectly possible to wrap a running Lwt loop after program
start, instrument it with hooks that fire on events before the regular
event processing, and use that to drive background collection. But
dynamically swapping the global loop looks horribly hackish to me, and
it certainly doesn't compose with other people swapping the loop too.

That question is really the only thing holding back at least the first
version of inter-event time harvesting.

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