There were some notes in the hypercall revision doc about random. JC: I think rumpuser_getrandom needs looking at. The only uses call the PRNG case not proper randomness. It should probably be a private interface for an in kernel driver that injects some real entropy at boot and occasionally later. There is no real reason to provide a PRNG interface as NetBSD has perfectly good ones and platforms might well not. If the platform cant provide real randomness then of course you cant run the driver.
AK: If the driver should be a part of every rump kernel, it technically should be in rumpkern. I want to avoid having more or less mandatory drivers outside of rumpkern, because it makes management of them quite difficult, i.e. if you always have to type "-lrumpkern_rnd -lrump", why not just making it "-lrump". If the hypercall interface is used incorrectly currently, it's one matter. If the interface prevents it from ever being used correct, it's a completely different matter. But the general idea is that host entropy is provided by the interface. If the host can't provide entropy, well, that's again another matter. I've document the [intentions of] rumpuser_getrandom() in the rumpuser man page. So, is the interface wrong, or just how it's currently used and implemented? JC: Currently it can provide access to either /dev/random or /dev/urandom, I dont really see the rationale for providing urandom access. In particular there is no way to estimate the amount of entropy it contains, so you cant feed the entropy estimate, so there is no way to provide a proper random source based on that. The blocking interface is not that useful. A host that doesnt have any entropy source (eg embedded system) is going to have to block forever. So the hard random nonblock case is the useful one. The interface consumers do need fixing, they only use the urandom interface. ------------------- Currently the implementation is very problematic. As I say above the only used case is RUMPUSER_RANDOM_HARD|RUMPUSER_RANDOM_NOWAIT ie we want real random numbers and do not wait if you do not have any right now. In terms of the hypercall revision, I think the interface need not change, but this is the only flag combination that should be supported or just ignore all flags and allow blocking always. The user might want to actually back it with a non hard RNG like /dev/urandom but thats a user implementation choice, not an API choice. Currently all the implementations actually give the same output whether HARD is specified or not, and none are really hard, with NetBSD using arc4random and Linux using random() seeded from /dev/random, which is a bit peculiar. Maybe the best option is a compile time option for rumpuser for hard or soft random numbers (probably defaulting to soft, as its ok for the default purposes in netbsd like tests, plus it is current behaviour). Then actually implement hard vs soft backends, which need to vary a fair amount by OS, ie netbsd is read /dev/random for hard, arc4random for soft, linux is read /dev/random or /dev/urandom and so on. I really want to get rid of the initialisation code, then all this can sit in one file shared by rumpuser and rumpfiber. Sounds reasonable? ------------------------------------------------------------------------------ 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
