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

On 7 Sep 2013, at 21:38, Ian Lepore <ian_at_FreeBSD.org> wrote:

> I keep trying to say this, and I keep getting the feeling that it just
> doesn't register with anyone I say it to, like I'm speaking some
> language from another planet or something...

Sorry.

I haven't forgotten this.

Right now, for 10.0, the intent is "Fix the bugs first". The all-singing
variant is going to follow.

> There may be NO entropy of any sort available on an embedded system, and
> you cannot block the ability to boot and run such a system just because
> you think it's a bad idea to run without sufficient randomness.  It's
> not your call to make -- it's a decision for the person using or
> administering the system.

True.

But the current fix for this (AKA the status quo) means that things are
broken for everyone, and I'm trying to get things "fixed by default" with
some kind of workaround for the folks that need it, rather than the other
way round.

> You must provide a mechanism that disables the blocking behavior.  The
> mechanism must be either a kernel compile-time config knob (not all
> platforms use loader(8) or anything else that can set a tunable var), or
> something in the rc system that can unblock /dev/random before anything
> else needs it.  The latter implies that the kernel itself must not block
> before getting to that point in rc processing, even if it needs random
> numbers for something (like cooking up a temporary MAC address).

Any kind of write to /dev/random (Yarrow) will unblock it. This may be
a matter of scripting in /etc/rc.d/<something>.

Like "echo '' > /dev/random", and it just needs to happen early enough,
i.e. before you do a blocking read.

> It's okay to make it hard to do the wrong thing by accident.  It's not
> okay to make it impossible to do that thing on purpose.

Again, true, but please bear in mind that things are suboptimal right now.

M
-- 
Mark R V Murray