[cc'ing Taylor, who probably (get it?) actually knows something about the subject]
_random_ thoughts ;) On 18/07/14 15:16, Justin Cormack wrote: > There were some notes in the hypercall revision doc about random. Even I had to think a while to remember where the discussion you quoted was from, so as a reference reference to others: https://github.com/rumpkernel/buildrump.sh/issues/59 > [copypaste from above url omitted] > 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. Again, some reference: Randomness was historically completely relegated to a hypercall. The interface is more or less a result of what I thought was appropriate when I was nailing down hypercall revision 17. I don't claim I thought about it exceedingly critically. As of some months ago, rump kernels include the NetBSD cprng. It is also the only consumer of rumpuser_getrandom(): http://nxr.netbsd.org/xref/src/sys/rump/librump/rumpkern/hyperentropy.c#43 The above hypercall cannot block, because it's run from a softint (due to how the cprng code in NetBSD works). Notably, the whole feedrandom() routine is a bit wrong, as it should persistently try to fetch more randomness until it can feed the cprng the amount of randomness it wants. This was pointed out by Taylor some months ago, but I've failed to fix it. I'm not quite sure how the cprng deals with someone requesting randomness from it in situations of insufficient entropy. > 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. That's just a very stupid implementation that was "first hack to get things going on Linux" and never got improved. Luckily, everyone knows who to blame. Let's just fix it. At least Linux seems to be growing some sort of getrandom() syscall now, which would be a good choice if available. > 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). Yea, maybe. I can't remember if the cprng wants to slurp in 8k entropy every time it's bootstrapped, or only when it's required. If you boot 1k rump kernels as part of tests, that's a lot of entropy that's potentially going completely unused. The only problem I see with these compile-toggles is that we're potentially shooting someone in the foot, i.e. someone thought they were getting hard random, but didn't know they had to turn some toggles on for it. Maybe a better choice is to default to safe, and have a runtime override (RUMPUSER_SOFTRANDOM?) for soft? > 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. Hum? If you want to read /dev/whatever, you can't get rid of the initialization code, since you need to open the device, and probably don't want to do that in every call. Apart from that, and potential input from Taylor nonwithstanding, sounds good. ------------------------------------------------------------------------------ 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
