Why almost every command is trying to read urandom?

[Michael Conrad]

On 11/12/19 2:47 PM, Mauro Condarelli wrote:
> In a recent kernel(5.x) / Buildroot / Busybox for an embedded system 
> (mips/MT7628, if it matters) I see TONS of:
> |random: mount: uninitialized urandom read (4 bytes read) random: 
> fsck.vfat: uninitialized urandom read (4 bytes read) random: tar: 
> uninitialized urandom read (4 bytes read) (Complete startup log below) |

I hadn't noticed before, but I just checked and my busybox 1.11 is doing 
this (reading /dev/urandom on every single applet startup) but I have a 
later busybox 1.30 which does not.

    strace busybox echo 2>&1 | grep rand

> This stops when, after a while (up to 10min later!!) I finally see: |[ 
> 562.001438] random: crng init done |
>
> Two questions:
>
>  1. why does it take so long to initialize /dev/urandom?
>  2. for what reason |mount| or |tar| should try to use it in the first
>     place?
>
> Note: I did NOT have this problem with older kernels (3.x).
>
1. /dev/random needs to "collect entropy" from unpredictable things like 
scheduler timing, human input devices, etc. /dev/urandom is then a 
less-secure source of random which gets initialized from /dev/random 
once the kernel is confident that /dev/random is random enough.  There 
are various places throughout the kernel code that feed entropy into the 
random pool, so changing kernels can change how fast it initializes.  
Busybox doesn't really have anything to do with this.  There might be 
some kernel options you need to explore to get things to initialize 
faster; but making it initialize faster might also be less secure.  You 
also have the option of writing some init script to preserve entropy 
from the previous boot and seed it after the reboot (by writing to 
/dev/random)

2. For one of the copies of busybox I have on hand, it appears that it 
initializes srand() at the startup of every single applet.  I don't see 
a reference to /dev/urandom in the current busybox source that would 
have this effect, so either busybox fixed it, or the behavior was coming 
from a particular libc used to build busybox.  My busybox with that 
behavior is statically linked, and I don't recall which libc it was.  
Since you just got yours out of a Buildroot, you should be able to 
investigate that easier.

-Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191112/36969f64/attachment.html>