On Mon, Jul 21, 2014 at 2:29 PM, Antti Kantee <[email protected]> wrote: > One more thing to take into consideration in revamping the hypercall is > that not necessary all platforms can deliver random numbers to guests > (e.g. Xen), except by collecting some random events and mixing and > mashing. For those platforms, we should just signal that getrandom() > never returns anything, and use the in-rump-kernel rnd_add_foo() to seed > the pool. That way we don't need to implement the tricky entropy > collection in the hypercall layer.
Agreed, it should return an error code rather than always returning no bytes. I don't really know why Xen does not have a host-provided random driver; KVM for example does. It might be helpful to document which parts need randomness, eg I imagine many filesystems do not. > Note, lack of platform randomness can be problematic especially on > short-lived guests, but not sure how we can produce something we don't have. RDRAND support in NetBSD would help for amd64 for hardware that supports it. Justin ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
