Re: rnd entropy estimate running low?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 31 Jan 2017 17:16:33 +0100 (CET)
> From: Havard Eidnes <he%NetBSD.org@localhost>
> 
> rnd: WARNING! initial entropy low (0).
> rnd: entropy estimate 0 bits
> rnd: asking source callout for 512 bytes
> rnd: system-power attached as an entropy source (collecting)
> mainbus0 (root)
> cpu0 at mainbus0 core 0: 1536 MHz Cortex-A5 r0p1 (Cortex V7A core)
> ...
> 
> I'm assuming this is because this happens too early, the rng
> device hasn't been detected so early in the boot process, and
> there's no file system accessible either to re-initialize the
> kernel rng from either at this stage, and the boot loader doesn't
> have a way to work around this.

The boot loader on x86, at least, can read a seed from the file system
(/var/db/entropy-file) before the kernel even starts, and that should
be fed in quite early.

> (This is more a platform-specific problem, I think, and
> tangential to what I discussed initially.)

Right, but it's an important one!  It is only in the system
engineering that you can get the entropy initialization correct -- no
amount of software can locally massage the inputs it has into a
high-entropy state, if the inputs are no good.  So for this platform
we should try to see when the HWRNG devices attaches and whether
anything needs to use entropy before then.

> OK, I'll buy the crypto argument at face value.  However, our code
> still behaves differently depending on whether the entropy estimate
> is able to "satisfy" the request being processed or not.  So under
> this description that is also a holdover from older versions of this
> code?

Yes.  There are two useful functions for blocking on reads from
/dev/random:

1. Waiting for initial entropy after the system to be booted, which
may mean, e.g., waiting until the on-board HWRNG device has provided
enough data.

2. Exercising the blocking code paths in applications, which would
otherwise occur only sometimes at system boot.

My draft rewrite of the entropy pool that I think you saw at the
devsummit at EuroBSDcon in Stockholm changes the decision of when to
block: if not enough entropy is available, block until it does; if
enough entropy is available, and a coin toss comes up heads, block up
to a second.

> It may be coincidental, but this box when it sits otherwise
> mostly idle and only does ntp for a long while sometimes logs
> 
> Kernel RNG "231 0 1" monobit test FAILURE: 10300 ones
> cprng 231 0 1: failed statistical RNG test
> ...
> 
> Admittedly, these are spread over a larger time period, and a
> couple of them were the result of provocation by dumping data
> from /dev/random with dd.

This is roughly to be expected from any stochastic test that has
nonzero false positive rate.  I have not computed exactly what the
false rejection rate is under the null hypothesis of uniform random
bits for these tests.  Someone^TM should do that!

(These are all classical frequentist hypothesis tests, mostly of
elementary chi^2, Binomial, &c., statistics on streams of ones and
zeros.  If anyone wants a little probability theory and statistics
exercise, I'd be happy to point you in the right direction for how to
do this.)

However, if it happens repeatedly over a short period of time, you
should be concerned that something is hosed in your kernel or HWRNG.