From owner-freebsd-current@FreeBSD.ORG Sat Nov 1 16:10:07 2014 Return-Path: Delivered-To: freebsd-current@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 64655488 for ; Sat, 1 Nov 2014 16:10:07 +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 3199E791 for ; Sat, 1 Nov 2014 16:10:06 +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 1XkbFd-0008yJ-4a; Sat, 01 Nov 2014 16:10:05 +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 sA1GA237087666; Sat, 1 Nov 2014 10:10:03 -0600 (MDT) (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+pN9E1kavdbFbUBxvxQV0W X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: CURRENT: WARNING! r273914 leaves filesystems in inconsistent/corrupted condition! From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86tx2j6k6j.fsf@nine.des.no> References: <20141031202045.2e02f4a3.ohartman@zedat.fu-berlin.de> <86a94c9bn3.fsf@nine.des.no> <545402C9.4070901@fgznet.ch> <201410312231.s9VMVsT1002148@pozo.com> <86fve392uy.fsf@nine.des.no> <20141101153554.77a4a7e4cef7bfe2b9486e89@dec.sakura.ne.jp> <86y4rv6lxf.fsf@nine.des.no> <1414852431.17308.210.camel@revolution.hippie.lan> <86tx2j6k6j.fsf@nine.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 01 Nov 2014 10:10:02 -0600 Message-ID: <1414858202.17308.214.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 sA1GA237087666 Cc: Tomoaki AOKI , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Nov 2014 16:10:07 -0000 On Sat, 2014-11-01 at 15:59 +0100, Dag-Erling Sm=F8rgrav wrote: > Ian Lepore writes: > > Dag-Erling Sm=F8rgrav writes: > > > That means we're not getting enough entropy during early boot, or > > > we're underestimating the amount of entropy we're getting. We adde= d > > > entropy harvesting to device_attach() about a year ago, which in > > > most cases provides enough entropy to unblock /dev/random before we > > > even run init(8). > > And I vaguely remember being promised that things like that would > > NEVER happen, even on systems with little or no entropy available > > during early startup (which describes quite nicely the embedded > > systems we build at work). >=20 > I think you misremember. It is impossible to guarantee that the system > will always have enough entropy right from the start. Servers, desktop= s > and laptops will be fine, but embedded systems and VMs might not be abl= e > to unblock until they've seen some network traffic or loaded a chunk of > pre-generated entropy (which is what /etc/rc.d/random does). This is > especially true for embedded systems that don't have enumerable buses > and rely on fdt(4) to create the device tree at boot time. >=20 And what about devices that are not connected to a network? We've been over this, I stressed again and again that we have an absolute requirement to start up reliably when there is NO ENTROPY. Saved entropy is great, if you've got some saved. Oh well, I'm sure I'll be able to find some hacks to undo whatever y'all have done now, and we'll just have to carry them as local diffs forever. -- Ian > VMs have the additional problem of divergence between clones: if you > clone a VM, all clones will start out with the exact same state and > won't diverge until they've all reseeded after gathering entropy > independently of eachother. I don't really know how to solve this. On= e > possibility, assuming you have guest additions installed and that they > can tell you that you've been suspended, is to block on resume. It > won't help VMs that were cloned while shut down, but they should diverg= e > to some extent during boot. >=20 > DES