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

Hi!


On 7 September 2013 13: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...
>
> 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.
>
> 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).
>
> 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.
>

We discussed this at the dev summit. Mark asked what we'd like to do.

Mark - would you mind terribly adding a kernel compile option that controls
that blocking default, so we can flip it on for the ARM/MIPS boards that
don't have a hardware PRNG to start seeding things with?



-adrian