From owner-freebsd-security@FreeBSD.ORG Thu Sep 27 22:10:23 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A85D1065675 for ; Thu, 27 Sep 2012 22:10:23 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CCCEF8FC1F for ; Thu, 27 Sep 2012 22:10:22 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 7B5086AE5; Fri, 28 Sep 2012 00:10:16 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 4E9A98473; Fri, 28 Sep 2012 00:10:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bruce Evans References: <20120918211422.GA1400@garage.freebsd.pl> <20120919192836.3a60cdfd@gumby.homeunix.com> <863923pzgi.fsf@ds4.des.no> <20120927125956.0594fa73@gumby.homeunix.com> <86pq57o7ps.fsf@ds4.des.no> <20120928062245.K4426@besplex.bde.org> Date: Fri, 28 Sep 2012 00:10:15 +0200 In-Reply-To: <20120928062245.K4426@besplex.bde.org> (Bruce Evans's message of "Fri, 28 Sep 2012 07:35:42 +1000 (EST)") Message-ID: <86fw63w20o.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, RW Subject: Re: Collecting entropy from device_attach() times. X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 22:10:23 -0000 Bruce Evans writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > RW writes: > > > binuptime(&bt); > > > return (bt.frac ^ bt.sec); > > Why the heck does it xor the integer and fractional parts together? > Because most of the entropy is in the fractional part, This is not about entropy, it's about implementing get_cyclecount() on a platform that doesn't have a TSC. It's supposed to be monotonic, and this implementation clearly isn't. Even when bt.sec is small enough that it doesn't affect significant digits of bt.frac (which should be most of the time, unless the resolution of the underlying timecounter exceeds ~2^32 Hz), get_cyclecount() will go backward every time a new second ticks over. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no