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

On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote:
> On 7 Sep 2013, at 19:36, Sean Bruno <sean_bruno_at_yahoo.com> wrote:
> 
> > On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote:
> >> On 7 Sep 2013, at 17:43, Sean Bruno <sean_bruno_at_yahoo.com> wrote:
> >>> trying to enable random on my DIR-825 kernconf I get this on boot:
> >>> 
> >>> Configuration file: /etc/cfg/hostapd.wlan0.conf
> >>> Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid "TESTBRUNO"
> >>> Entropy device is blocking
> >> 
> >> Please make a change to sys/dev/random/randomdev_soft.c;
> >> 
> >> Around line 82, please change from ".seeded = 0" to ".seeded = 1".
> >> 
> >> If that works, then your report above with the "Entropy device is blocking."
> >> is trying to read random numbers before /dev/random is secure; this is a BAD
> >> security problem. 
> >> 
> >> M
> > 
> > 
> > Looks like it does indeed work if that is set to 1.  
> > 
> > This "DIR-825" config, should be loading random as a module, not built
> > into the kernel due to size limitations of the kernel on this board.
> 
> Hmm. I'll set it back to 1, but this is technically a security issue.
> 

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.

-- Ian

> Thanks for the report back, and sorry for the hassles!
> 
> M