> Date: Tue, 31 Jan 2017 17:16:33 +0100 (CET) > From: Havard Eidnes <h...@netbsd.org> > > 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.