{"action":"created","issue":{"url":"https://api.github.com/repos/mirage/mirage-entropy/issues/9","labels_url":"https://api.github.com/repos/mirage/mirage-entropy/issues/9/labels{/name}","comments_url":"https://api.github.com/repos/mirage/mirage-entropy/issues/9/comments","events_url":"https://api.github.com/repos/mirage/mirage-entropy/issues/9/events","html_url":"https://github.com/mirage/mirage-entropy/issues/9","id":56136109,"number":9,"title":"Support entropy from RDSEED","user":{"login":"djs55","id":198586,"avatar_url":"https://avatars.githubusercontent.com/u/198586?v=3","gravatar_id":"","url":"https://api.github.com/users/djs55","html_url":"https://github.com/djs55","followers_url":"https://api.github.com/users/djs55/followers","following_url":"https://api.github.com/users/djs55/following{/other_user}","gists_url":"https://api.github.com/users/djs55/gists{/gist_id}","starred_url":"https://api.github.com/users/djs55/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/djs55/subscriptions","organizations_url":"https://api.github.com/users/djs55/orgs","repos_url":"https://api.github.com/users/djs55/repos","events_url":"https://api.github.com/users/djs55/events{/privacy}","received_events_url":"https://api.github.com/users/djs55/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-01-31T19:28:47Z","updated_at":"2015-02-02T21:23:10Z","closed_at":null,"body":"On modern Intel boxes `RDSEED` is a good source of entropy (probably)"},"comment":{"url":"https://api.github.com/repos/mirage/mirage-entropy/issues/comments/72540611","html_url":"https://github.com/mirage/mirage-entropy/issues/9#issuecomment-72540611","issue_url":"https://api.github.com/repos/mirage/mirage-entropy/issues/9","id":72540611,"user":{"login":"mor1","id":167904,"avatar_url":"https://avatars.githubusercontent.com/u/167904?v=3","gravatar_id":"","url":"https://api.github.com/users/mor1","html_url":"https://github.com/mor1","followers_url":"https://api.github.com/users/mor1/followers","following_url":"https://api.github.com/users/mor1/following{/other_user}","gists_url":"https://api.github.com/users/mor1/gists{/gist_id}","starred_url":"https://api.github.com/users/mor1/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mor1/subscriptions","organizations_url":"https://api.github.com/users/mor1/orgs","repos_url":"https://api.github.com/users/mor1/repos","events_url":"https://api.github.com/users/mor1/events{/privacy}","received_events_url":"https://api.github.com/users/mor1/received_events","type":"User","site_admin":false},"created_at":"2015-02-02T21:23:10Z","updated_at":"2015-02-02T21:23:10Z","body":"i can't speak to how best to patch `Lwt_engine` but regarding describing\nsource combinations in `config.ml`: perhaps one should view entropy as\nsufficiently important that it must be explicitly specified by the\ndeveloper and that's that?\n\nthat is, if she wants unikernels that work on different platforms, she\ncompiles different images (`--entropy-aws`, `--entropy-xentropyd`, etc if i\nhave the right idea of @nojb's patches to mirage cli). if she wants\ncomplicated behaviour, she can code it up as she likes-- but we don't try\nto second guess *anything*.\n\n\nOn 2 February 2015 at 21:08, David Kaloper <notifications@github.com> wrote:\n\n> It is good, and even RDRAND is (it runs AES-CTR for no more than 511\n> consecutive steps reseeding it with what became RDSEED). And I have two\n> papers arguing that at least on x86, the CPU is so inherently prone to data\n> races due to several levels of paralelism and caching effects, that its\n> physical behaviour can reasonably be treated as nondeterministic -- which\n> suggests reading the cycle counter every now and then should yield a steady\n> trickle of entropy. These two things are used by both haveged\n> <http://www.issihosts.com/haveged/> and Whirlwind RNG\n> <http://www.ieee-security.org/TC/SP2014/papers/Not-So-RandomNumbersinVirtualizedLinuxandtheWhirlwindRNG.pdf>\n> .\n>\n> What's even better, both instructions can be exposed to OCaml with about 4\n> lines of C each (returning Val_long and bypassing GC just to be\n> super-awesome).\n>\n> What's not so good is that both these sources (*especially* the cycle\n> counter) need to be checked periodically, as a single sample is not\n> sufficient (and in general the rng is built to recover from state\n> compromise *provided* there is a steady influx of entropy). This probably\n> calls for piggy-backing on the event mechanism already in place, to avoid\n> constantly waking up the system in the background.\n>\n> The interface <http://ocsigen.org/lwt/2.4.7/api/Lwt_engine> is too\n> constrained for that, but it can be worked around\n> <https://github.com/mirleft/ocaml-tls/blob/master/lwt/tls_lwt.ml#L288>\n> with a fragile hack. With a hook in place, of type unit -> unit that gets\n> called whenever Lwt is ready to dispatch an event, adding these two\n> sources of entropy is a matter of 15 minutes.\n>\n> The real problem here is what would a more general interface for trapping\n> any activity in an Lwt_engine.t look like? Pre-fire? Post-fire?\n> Controllable? With a single callback? A queue? Etc. We need to come up with\n> a coherent design before PR-ing that to lwt people.\n>\n> And the really ugly part is the fact that various platforms can expect\n> wildly varying support for different mechanisms of obtaining entropy. How\n> do we expose that to config.ml?\n>\n> Having one_entropy and another_entropy, where the blue one reads from\n> xentropyd and the red one uses builtin instructions? What happens with\n> processors that don't support some of the instructions? Disable the red one\n> at compile-time? What does compositionality of those sources look like? How\n> can they be mixed?\n>\n> *TL;DR*\n> What's stopping us from having proper entropy is the lack of clarity on\n> how to describe source combinations in config.ml, how to patch Lwt_engine\n> and how the two should interact.\n>\n> --\n> Reply to this email directly or view it on GitHub\n> <https://github.com/mirage/mirage-entropy/issues/9#issuecomment-72538013>.\n>\n\n\n\n-- \nRichard Mortier\nmort@cantab.net"}}