RFC: xen: read entropy from the Xen entropy device

We connect to an entropy server over the well-known console channel

  org.openmirage.entropy.1

Limitations:

- we read exactly one block of entropy data. Should we read as much
  as the backend will offer? Note the backend implementation has a
  rate limiter to avoid starving dom0.
- there is no fall-back for cases where there is no Xen entropy source
  i.e. on the vast majority of Xen hosts including AWS.

Signed-off-by: David Scott <dave.scott@citrix.com>
That's why I thought I'd better phrase is as an RFC-- it seems to me that
if you really care about generating good keys, you would rather fail/block
than fall back, otherwise if xentropyd falls over you might not notice the
problem until it's too late. However there are lots of cases where you
won't have a xentropyd (like AWS) where there's no real choice.

Perhaps the app writer should choose some kind of policy?

- strict
- dontcare
- tryabitboforegivingup
?

On Sun, Dec 21, 2014 at 9:06 PM, Anil Madhavapeddy <notifications@github.com
> wrote:
>
> In xen/entropy_xen.ml
> <https://github.com/mirage/mirage-entropy/pull/8#discussion-diff-22150306>
> :
>
> >
> >  let connect () =
> > -  Random.self_init ();
> > -  print_endline "Entropy_xen_weak: using a weak entropy source seeded only from time.";
> > -  return (`Ok { handler = None })
> > +  Printf.printf "Entropy_xen: attempting to connect to Xen entropy source %s\n%!" console_name;
> > +  Console_xen.connect console_name
>
> doesn't this need to fallback to weak if the xentropyd isnt listening?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/mirage/mirage-entropy/pull/8/files#r22150306>.
>


-- 
Dave Scott