From owner-svn-src-head@FreeBSD.ORG Thu Mar 17 13:09:43 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17C521065670; Thu, 17 Mar 2011 13:09:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id A14068FC1C; Thu, 17 Mar 2011 13:09:42 +0000 (UTC) Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2HD9cq4012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 00:09:40 +1100 Date: Fri, 18 Mar 2011 00:09:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Maxim Dounin In-Reply-To: <20110316140042.GN99496@mdounin.ru> Message-ID: <20110317235541.E1128@besplex.bde.org> References: <201103151714.p2FHEQdF049456@svn.freebsd.org> <20110315193306.GK99496@mdounin.ru> <201103151555.45816.jkim@FreeBSD.org> <201103151631.34418.jkim@FreeBSD.org> <20110316163507.F4107@besplex.bde.org> <20110316140042.GN99496@mdounin.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Jung-uk Kim , Bruce Evans Subject: Re: svn commit: r219672 - in head: share/man/man9 sys/i386/include X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 13:09:43 -0000 On Wed, 16 Mar 2011, Maxim Dounin wrote: > On Wed, Mar 16, 2011 at 04:44:35PM +1100, Bruce Evans wrote: > >> On Tue, 15 Mar 2011, Jung-uk Kim wrote: >>>> On Tuesday 15 March 2011 03:33 pm, Maxim Dounin wrote: >>>>> Note that on early boot only dummy timecounter available, and >>>>> binuptime() has no entropy. >> ... >> Is dummy timecounter used for long enough to matter? I think completion >> of clock initialization is still bogusly late for histrotical reasons, >> but there is still a second or two between completion of timecounter >> initialization and user mode. The earlier stages of booting might >> take 20 seconds but should be faster, so they might not provided much >> more entropy from clocks. > ... > Right now the only entropy used at early boot are from > get_cyclecount() call, which has at least some entropy on most > platforms (notable exceptions are arm and i386 with i486 cpus). > With dummy timecounter there are no entropy at early boot. I see. I thought that counters were almost useless for entropy. But the TSC normally has a very high frequency, so there is some entropy in its low bits. I think timecounters preserve all the bits of the low-level counter in some form (this is possible since bintimes have even more bits than the TSC). So binuptime() should give about the same entropy as rdtsc() when the timecounter is the TSC. But the timecounter usually isn't the TSC. Its low-level timer usually has a relatively low frequency (14 MHz for ACPI-fast), so it doesn't have much entropy in its low bits, and binuptime() doesn't work well for gathering entropy even if the timecounter is not the dummy one. I think it is bogus that get_cyclecount(9) even mentions monotonicity. It emphasizes monotonicy and doesn't mention entropy (except indirectly by saying that SMP may have CPUs with independent monotonic sequences). > If you want to change get_cyclecount() to be alias to binuptime() > - we may consider adding another machdep call to extract early > entropy. Much better to name it extract_early_entropy() than get_monotonic_cyclecount(). > I still not quite understand the reasons though. I consider > binuptime() to be some (bad one) fallback for get_cyclecount() on > platforms which has no hardware counter available. Moving all > platforms to bad fallback looks strange. Maybe the dummy timecounter was not the main problem since other counters take over soon enough, but other counters don't give enough entropy unless they are high frequency which is rare. Bruce