really odd 0.45 startup behavior

[Matt Johnston]

On Thu, Apr 21, 2005 at 07:02:32PM -0400, Paul Fox wrote:
> if during the first couple of minutes after boot, an scp is done to copy
> a file off of the embedded device, performance is very slow.  i.e.,
> this command executed from a different host:
>     scp root at ppc:/bin/busybox /tmp
> will take upwards of 30 seconds to complete, but only for the first
> couple of minutes of uptime.  after that, it runs very quickly.
> 
> i know, this doesn't sound like a dropbear problem, except that
>     a) release 0.43 doesn't show this behavior, and
>     b) if i strace the 0.45 dropbear server while this is happening,
>      i see the following suspicious behavior -- continuous
>      writes of 0 bytes from a null buffer.  this can't be right.

*sigh* Seems to be yet another manifestation of the problem
of insufficient entropy at startup. (see
http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q1/000151.html
as a previous report). It's a hasslesome problem of embedded
environments.

Thanks to your helpful strace, the thing that gives it away
is:

> 1111  22:16:32.695085 pipe([4, 6])      = 0
> 1111  22:16:32.695473 pipe([8, 9])      = 0
> 1111  22:16:32.695841 pipe([10, 11])    = 0
> 1111  22:16:32.696283 fork()            = 1123    <- this forks what will
                                                       become the scp process
> 1111  22:16:32.697624 close(4 <unfinished ...>
> 1123  22:16:32.698134 dup2(4, 0 <unfinished ...>
*snip*
> 1123  22:16:32.702817 close(9)          = 0
> 1123  22:16:32.703159 close(10)         = 0
> 1123  22:16:32.703425 close(11)         = 0
> 1123  22:16:32.703968 open("/dev/random", O_RDONLY) = 4   <- try to reseed
> 1123  22:16:32.704393 read(4, "\'\202!\375", 32) = 4
> 1123  22:16:32.704822 read(4,  <unfinished ...>

And here the read() on /dev/random blocks. The reasoning
here is that the "child" dropbear process (which will soon
execve() into a scp process) has to reseed the random number
generator to avoid the user-privileged child process having
any knowledge of the state of the random number generator,
which could potentially still be used with secret hostkeys.

Unfortunately, at startup many embedded devices don't have
enough entropy available, so will just sit there until some
is available. Possible solutions are kernel patches to add
network events to the random pool, or storing a seed between
boots. As I mentioned in the email referenced above, if you
can be sure that there's enough entropy in the system, just
using urandom should be OK. (The device to use is defined in
options.h, and changed from /dev/random->/dev/urandom in
0.44).

The nicest solution would probably be for the kernel
developers to provide an interface that blocked until the
system has reached a sufficiently unguessable state, and
then just behaves like /dev/urandom.

Regarding the zero/null writes, I think they're probably
from common-channel.c, where the zero-writes are used to
'probe' whether a socket (to a forked process etc) has been
closed.

Cheers,
Matt