Re: random(4) update causes mips compile fail | mips boot fail

Glen Barber <gjb_at_FreeBSD.org> writes:
> The correct workaround (which now I see I should have done before
> locking head/) is to revert this commit so it can be properly fixed.

Glen, to be fair, the mips boot fails because they're trying to use a
device before it's ready.  It just so happens that this device is
implemented entirely in software, not in hardware, but it's no different
from trying to read from an empty optical drive.  The only thing that
has changed, in practical terms, is that previously if they tried to
read from an empty drive (to continue the analogy) we'd nod and smile
and feed them zeroes, whereas now we wait for someone to insert a disc.

So Mark didn't really break anything here (apart from the build breakage
which has already been fixed), he just made an existing bug visible.
And he's already reverted the *one* line of code that did this, so mips
is now almost as broken as it was before (only almost, because the first
commit also fixed some serious harvesting / entropy estimation bugs).

Anyway, on platforms that support tunables, this should help:

Index: sys/dev/random/randomdev_soft.c
===================================================================
--- sys/dev/random/randomdev_soft.c	(revision 255371)
+++ sys/dev/random/randomdev_soft.c	(working copy)
_at__at_ -102,6 +102,8 _at__at_
 
 #endif
 
+TUNABLE_INT("kern.random.sys.seeded", &random_context.seeded);
+
 /* List for the dynamic sysctls */
 static struct sysctl_ctx_list random_clist;
 
On platforms that don't, we need to figure out a better solution;
possibly Pawel's early harvesting patch, which, while not perfect, at
least introduces a minimum of entropy into Yarrow before boot.

DES
-- 
Dag-Erling Smørgrav - des_at_des.no