From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 18:57:50 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B33C334; Fri, 21 Nov 2014 18:57:50 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF125B17; Fri, 21 Nov 2014 18:57:49 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XrtOu-0001WM-4j; Fri, 21 Nov 2014 18:57:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sALIvkxd004133; Fri, 21 Nov 2014 11:57:46 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+vICsXSoFBgaE2AEHrglZS X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274739 - head/sys/mips/conf From: Ian Lepore To: Mark R V Murray In-Reply-To: <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> Content-Type: text/plain; charset="iso-8859-7" Date: Fri, 21 Nov 2014 11:57:46 -0700 Message-ID: <1416596266.1147.290.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sALIvkxd004133 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:57:50 -0000 On Fri, 2014-11-21 at 18:45 +0000, Mark R V Murray wrote: > > On 21 Nov 2014, at 15:16, Ian Lepore wrote: > >=20 > >> If you can demonstrate a usable system w/o much modifications that > >> runs w/ the dummy interface, or no boot random, that I'll drop my > >> suggestion... I'll try removing random tomorrow and see what breaks= ... > >>=20 > >=20 > > If your point is that after the recent commits you can no longer do > > these things, then I guess that's kind of hard to argue with given th= at > > some of us have been trying to say for a couple years that if=20 > > /dev/random starts blocking to wait for entropy at startup, existing > > *functional* small systems will stop working. >=20 > As a fair bit of the security subsystem depends on working /dev/random, > this is true. >=20 > HOWEVER - I=A2m most willing to entertain ideas on how to get a general > config going that disables anything that is /dev/random-dependant. >=20 > Asking the SO to break sshd(8) isn=A2t going to work, but enabling > (say) telnet and/or rsh in the !random(4) case could be a way to do > it. >=20 > > Before those changes everything worked fine on the 90mhz 64MB arm > > systems we build products around, which have no more than a few bits = of > > entropy available during the boot process, and which (I'll say it aga= in > > even though nobody has ever paid any attention to it) don't actually > > need any entropy to come up and do what it is they are designed to do. > >=20 > > They don't use https (a few of them don't even have network > > connections). They use ssh for its convenience (it's better than > > telnet), but NOT for security. (And really, whether that makes sense= to > > you or not, "the system must be secure" is not your decision to make.= ) >=20 > Why not just use rsh? If the security overhead is onerous, don=A2t use = it. >=20 > > I haven't tested a recent -current on those small systems, but we've > > already resigned ourselves to sticking with 8.x for those older board= s > > just because the tide of bloat (both code and policy) is too much to > > swim against. >=20 > Yet you use ssh? >=20 > M All I've ever asked for, since day one of discussing this topic, is a knob to prevent /dev/random from blocking, ever. A way in which an administrativive policy decision can be made about what consitutes "good enough" entropy (and by extension, security). The knob could be of the nature that it's hard to turn on accidentally -- it's a dangerous thing and like an industrial stamping press maybe you have to hold down two buttons far apart from each other to make it go. As far as I know we have that now, but it sounds like not forever. I'm just arguing in favor of providing the tools, making it reasonably hard to accidentally cut yourself on them, but ultimately leaving the policy decisions of how to use them to the people who own and run the systems. I kind of thought that was the unix way. -- Ian