From owner-svn-src-head@FreeBSD.ORG Wed Mar 16 14:26:31 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 0E047106566C; Wed, 16 Mar 2011 14:26:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 90EDE8FC0C; Wed, 16 Mar 2011 14:26:30 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2GEQQdT091578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 16:26:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2GEQQd3062492; Wed, 16 Mar 2011 16:26:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2GEQQRj062491; Wed, 16 Mar 2011 16:26:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Mar 2011 16:26:26 +0200 From: Kostik Belousov To: Maxim Dounin Message-ID: <20110316142626.GP78089@deviant.kiev.zoral.com.ua> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gqBxMmDy+0ucIclE" Content-Disposition: inline In-Reply-To: <20110316140042.GN99496@mdounin.ru> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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: Wed, 16 Mar 2011 14:26:31 -0000 --gqBxMmDy+0ucIclE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2011 at 05:00:42PM +0300, Maxim Dounin wrote: > Hello! >=20 > On Wed, Mar 16, 2011 at 04:44:35PM +1100, Bruce Evans wrote: >=20 > > On Tue, 15 Mar 2011, Jung-uk Kim wrote: > >=20 > > >On Tuesday 15 March 2011 03:55 pm, Jung-uk Kim wrote: > > >>On Tuesday 15 March 2011 03:33 pm, Maxim Dounin wrote: > > >>>Hello! > > >>> > > >>>On Tue, Mar 15, 2011 at 05:14:26PM +0000, Jung-uk Kim wrote: > > >>>>Author: jkim > > >>>>Date: Tue Mar 15 17:14:26 2011 > > >>>>New Revision: 219672 > > >>>>URL: http://svn.freebsd.org/changeset/base/219672 > > >>>> > > >>>>Log: > > >>>> Unconditionally use binuptime(9) for get_cyclecount(9) on > > >>>>i386. Since this function is almost exclusively used for random > > >>>>harvesting, there is no need for micro-optimization. Adjust > > >>>>the manual page accordingly. > > >>> > > >>>Note that on early boot only dummy timecounter available, and > > >>>binuptime() has no entropy. > >=20 > > >>>As a result of this change random(9) won't have entropy on early > > >>>boot on i386, and arc4random(9) as well. While there are no > > >>>known major security problems associated with it - it at least > > >>>makes stack protector easily bypasseable as it now (again after > > >>>r198295) uses well-known stack guard instead of random one. And > > >>>there may be other issues as well. > >=20 > > 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. >=20 > The problem is initial random number generator initialization=20 > (random(9) and acr4random(9)) and various early boot things which=20 > use random. Most notably it's stack protector (which has to be=20 > initialized as early as possible, and requires special handling of=20 > code which is run before it's initialized), but there are also other=20 > things to care about - AFAIR booting from nfs uses the same ports=20 > without entropy and so on. >=20 > Right now the only entropy used at early boot are from=20 > get_cyclecount() call, which has at least some entropy on most=20 > platforms (notable exceptions are arm and i386 with i486 cpus).=20 > With dummy timecounter there are no entropy at early boot. >=20 > After boot everything is eventually reseeded (random(9) at=20 > proc0_post(), arc4random(9) and /dev/random at userland startup=20 > scripts) and becomes safe. proc0_post() is not called after the boot, it is executed during the boot. Why is the randomness for the stack protector critical at that stage ? Most kernel threads are started after INTRINSIC_POST, at least this is what I see from looking at kernel.h.=20 Might be, the ssp initialization should be moved after SI_SUB_INTRINSIC_POS= T ? This is definitely irrelevant for usermode ssp, since the first thread enters usermode long after the INTRINSIC_POST is done. >=20 > > I have entropy stuff mostly turned off and often don't even have enough > > entropy to run ed on /etc/fstab early. Don't know if I have clock entr= opy > > turned off. > >=20 > > >>>Hope you thought well before moving i386 to a set of platforms > > >>>which have no early boot randomness at all. And you have good > > >>>reason for doing it. > >=20 > > I asked for moving all platforms to binuptime() so that the bugs could > > be seen by everyone :-). Didn't know about this bug. >=20 > If you want to change get_cyclecount() to be alias to binuptime()=20 > - we may consider adding another machdep call to extract early=20 > entropy. >=20 > I still not quite understand the reasons though. I consider=20 > binuptime() to be some (bad one) fallback for get_cyclecount() on=20 > platforms which has no hardware counter available. Moving all=20 > platforms to bad fallback looks strange. >=20 > Maxim Dounin --gqBxMmDy+0ucIclE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2AyJAACgkQC3+MBN1Mb4gmggCgjc8o4PlBd4Ar4ujsL952psJR z/8AoKUSN7DcRtF6B9rcNC9HjI//iXLf =Oa5C -----END PGP SIGNATURE----- --gqBxMmDy+0ucIclE--