I just sent a long answer to Rob (with a sum up at the beginning)
2016-07-06 18:39 GMT+02:00 Denys Vlasenko <vda.li...@googlemail.com>: > I think Rob's getting somewhat too agitated here, but his arguments > are convincing. > > On Wed, Jul 6, 2016 at 4:33 AM, Rob Landley <r...@landley.net> wrote: >>> Entropy collection is slower on embeded devices, so you have to wait for >>> it, and >>> getrandom() claim to do exactly that >> >> By adding 3 minutes to the boot time? >> >> Look, I'm tired of this. It's not my call if this goes into busybox, >> it's Denysy's. I was just readign to see if it was a thing I should do >> in toybox. But I don't see what the point is of adding it to either >> package. If you want this command it's 5 lines of code and you can >> compile it yourself. I do not see what purpose it serves. >> >> I'm going to start skimming now. >> >>>> What is your use case? Why are you bothering to do this? >>>> >>>> It's entirely possible your new approach is superior, but you have not >>>> successfully articulated _why_ yet. Would you like to try again? >>> >>> Of course :) >>> After heartbleed openbsd people forked openssl in libressl, and >>> started to clean things up, >>> they saw that there was no good way to get entropy in the linux world >>> (file descriptor exhaution) >> >> That's like saying there's no good way to get _input_ in the linux >> world, due to file descriptor exhaustion. No good way to get data from >> disk! No good way to get data from the network! Woe is us! Calamity! >> It's impossible to implement ps because it needs /proc to be mounted! >> >> Seriously? >> >> If your function allocates memory, it should be able to return failure >> if it couldn't. If your function opens a file, it should be able to >> return failure if it couldn't. Why is this a hard concept? > > I agree. If the tool wants to be paranoid and it decided that > it absolutely must read /dev/[u]random, then it's completely fine > for this tool to simply fail if it can't do that. > > >>> Theodore Ts'o while at it added the possibility to block until >>> /dev/urandom as been seeded with 128bits of entropy, specifically >>> targetting embeded systems >>> https://lwn.net/Articles/605828/ >> >> Yes, I read it. I am not convinced. I tried it and got almost 3 minutes >> of blocking. (Reading 1 byte from /dev/random with dd gave me 6 minutes >> of blocking, but I suspect the wget initialized the random state a bit. >> Busybox dd was already in the image so I didn't need to wget it...) > > getrandom() being faster to unblock than /dev/random indeed feels... > "wrong". I would imagine there should be only one measure > of "cryptographcally secure" in kernel, not two. > When the pool is deemed "cryptographcally securely seeded", > both APIs should unblock. Maybe filing a bug is in order. Not a bug, it's how it's designed, see my answer to Rob, 2 pools, /dev/urandom pool is seeded before /dev/random pool (there is also a 3rd pool, the input pool) > > Etienne, for now I think the goal you seek can be achieved by blocking on > small read from /dev/random. take 2 times more to unblock, and might block again > > You may be able to speed it up > by forking a child which makes system less quiescent. > > For example, in the current tree, release_task() -> __exit_signal() -> > -> posix_cpu_timers_exit() -> > -> add_device_randomness((const void*) &tsk->se.sum_exec_runtime, > sizeof(unsigned long long)); > > Evidently, as of now, task runtime is treated as "somewhat random" > by kernel. While "dd bs=1 count=1 </dev/random >/dev/null" waits, > run a chile which continually forks "sleep 0". This will likely > make dd wake up sooner. My applet is only 207K, and if i'm doing C, i will use getrandom() Regards Etienne _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox