From owner-freebsd-current@FreeBSD.ORG Sat Sep 7 21:36:45 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3F4F8E0; Sat, 7 Sep 2013 21:36:44 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCBFC26A1; Sat, 7 Sep 2013 21:36:43 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VIQBM-000Dt2-OA; Sat, 07 Sep 2013 22:36:42 +0100 Subject: Re: random(4) update causes mips compile fail | mips boot fail Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_38D72C6E-6501-4786-A2D8-CB027205742B"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <1378586316.1111.524.camel@revolution.hippie.lan> Date: Sat, 7 Sep 2013 22:36:39 +0100 Message-Id: <82260B0E-E2CF-4D7B-B1E2-EEFAF25BD090@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> <1378586316.1111.524.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 X-Mailman-Approved-At: Sat, 07 Sep 2013 21:56:49 +0000 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 21:36:45 -0000 --Apple-Mail=_38D72C6E-6501-4786-A2D8-CB027205742B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 7 Sep 2013, at 21:38, Ian Lepore 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/. 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 --Apple-Mail=_38D72C6E-6501-4786-A2D8-CB027205742B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUiucZ958vKOKE6LNAQqMAQP/Qp0Yeb7xfbHBlUTIOVkUXEEv8s7xHWr+ Zy9mQSVu+Ih4CP+tIGXpX+eADYe3MN3EXdUwWw4gvhhSuKT8OMSq0FmMFJiqsyOJ dM/CY1nvk9oSqL9iuNAAeg3Wz7O34dzoDMegNLuEsrXtf6Fd2AVu/ca3cELVYmom s75rUcJT91c= =paib -----END PGP SIGNATURE----- --Apple-Mail=_38D72C6E-6501-4786-A2D8-CB027205742B--