On Fri, Mar 27, 2015 at 4:49 PM, Anil Madhavapeddy <[email protected]> wrote: > On 27 Mar 2015, at 15:16, Thomas Gazagnaire <[email protected]> wrote: >> >> Hi, >> >>> And the question I am raising is: Are there objections to this? Did >>> anyone want to code something that requires direct access to entropy >>> sources (i.e. another RNG)? Did anyone want to make a separate entropy >>> provider? >> >> I think that's a good idea. We should still keep the modular approach of >> MirageOS (ie. having separate librarie(s) to deal with entropy) but I'm fine >> to remove the ENTROPY signature for V1 and V1_LWT as it doesn't bring much >> (apart from confusion it appears).
Yes, absolutely. I did not actually want to inline various libraries into one; rather, I'm arguing that we introduced a bit of unintended generality by adding a public interface ahead of actual need, and that we can simplify the system by backing out a bit. > I'm also fine with this approach. Just one thing that would be good > to define would be which our "singleton" devices are. In the case of > entropy, it's extremely unlikely that you would want to have a > non-shared mixer, so perhaps we should enforce that explicitly in the > Mirage config eDSL... > > It would also be good to port the TCP/IP stack to using nocrypto at > the same time, to give it the IP ID and TCP ISN random sources, and > to have more than one consumer outside of the TLS stack. This is a > very localised patch -- it currently uses the Random module directly. This follows from equipping Nocrypto with the existing Mirage RANDOM signature (almost trivial). I think no further changes to anything else are needed, as TCP is already functorized over RANDOM. Thomas' objection to GMP still applies, though, but there would be no coupling. _______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
