From owner-freebsd-current@FreeBSD.ORG Sat Sep 7 20:38:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C37E79D9; Sat, 7 Sep 2013 20:38:40 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 964C42426; Sat, 7 Sep 2013 20:38:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VIPHD-0006ek-DX; Sat, 07 Sep 2013 20:38:39 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r87KcauW074880; Sat, 7 Sep 2013 14:38:36 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18nZ12k4XeARzuj2aTfVGmo Subject: Re: random(4) update causes mips compile fail | mips boot fail From: Ian Lepore To: Mark R V Murray In-Reply-To: <9240BEF1-2791-4D58-A422-08AEF1CD306C@grondar.org> References: <1378572186.1588.5.camel@localhost> <24DB010A-F374-491B-9203-FDDD7EA14A51@grondar.org> <1378579011.1588.16.camel@localhost> <9240BEF1-2791-4D58-A422-08AEF1CD306C@grondar.org> Content-Type: text/plain; charset="us-ascii" Date: Sat, 07 Sep 2013 14:38:36 -0600 Message-ID: <1378586316.1111.524.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 20:38:40 -0000 On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote: > On 7 Sep 2013, at 19:36, Sean Bruno wrote: > > > On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote: > >> On 7 Sep 2013, at 17:43, Sean Bruno 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