From owner-freebsd-security@FreeBSD.ORG Mon Sep 10 19:21:46 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 4F838106566C; Mon, 10 Sep 2012 19:21:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 3CBA314EDA4; Mon, 10 Sep 2012 19:21:16 +0000 (UTC) Message-ID: <504E3DAB.3090000@FreeBSD.org> Date: Mon, 10 Sep 2012 12:21:15 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <20120907015157.GA29497@server.rulingia.com> <20120910135218.GA68128@dragon.NUXI.org> <504E343A.4020802@FreeBSD.org> <86pq5tu1zr.fsf@ds4.des.no> In-Reply-To: <86pq5tu1zr.fsf@ds4.des.no> X-Enigmail-Version: 1.4.4 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Arthur Mesh , freebsd-rc@freebsd.org, freebsd-security@freebsd.org, RW , Xin Li Subject: Re: svn commit: r239569 - head/etc/rc.d 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: Mon, 10 Sep 2012 19:21:46 -0000 On 9/10/2012 12:11 PM, Dag-Erling Smørgrav wrote: > Doug Barton writes: >> As I have repeated many times now, BEFORE YOU MAKE ANY MORE CHANGES I AM >> ASKING YOU TO DO THE TESTING TO VERIFY YOUR CLAIMS. > > And here's the million-dollar question... how? Boot a VM a million > times, save the first 4096 bytes that come out of /dev/random at every > boot, and look for correlation? If the problem with replay attacks is as bad as Arthur suggest it is, it should be visible in far less than a million tries. For the "how much entropy makes it into the pool" question instrumenting the code should do the trick. My point being that we have 12 years of successful operation, with no one (TMK) complaining that they have actually _seen_ the alleged problems in action. Now we have claims that major problems exist, requiring drastic changes in the system. As I have said before, it would be bad engineering to make these changes without proof under any circumstances. Even more so given that /dev/random is (in some senses) a security tool. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)