From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 13:55:02 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53B1E10656F2; Wed, 5 Sep 2012 13:55:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9E68FC19; Wed, 5 Sep 2012 13:55:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50D4DB95E; Wed, 5 Sep 2012 09:55:01 -0400 (EDT) From: John Baldwin To: freebsd-security@freebsd.org Date: Wed, 5 Sep 2012 09:44:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201208222337.q7MNbORo017642@svn.freebsd.org> <20120905021248.5a17ace9@gumby.homeunix.com> <5046D7F0.1000601@FreeBSD.org> In-Reply-To: <5046D7F0.1000601@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209050944.38042.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Sep 2012 09:55:01 -0400 (EDT) Cc: RW , Doug Barton Subject: Re: svn commit: r239598 - 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: Wed, 05 Sep 2012 13:55:02 -0000 On Wednesday, September 05, 2012 12:41:20 am Doug Barton wrote: > Can you point out where in the source you're seeing these things? He did. A write to /dev/random calls random_write() in randomdev.c. In the pure software case, the 'random_systat.write()' that is called in the loop in random_write() is random_yarrow_write() in randomdev_soft.c. That function calls random_harvest_interval() splits up the input data into chunks of HARVESTSIZE bytes (or less for the final bit of data). HARVESTSIZE is 16: void random_yarrow_write(void *buf, int count) { int i; u_int chunk; /* * Break the input up into HARVESTSIZE chunks. The writer has too * much control here, so "estimate" the entropy as zero. */ for (i = 0; i < count; i += HARVESTSIZE) { chunk = HARVESTSIZE; if (i + chunk >= count) chunk = (u_int)(count - i); random_harvest_internal(get_cyclecount(), (char *)buf + i, chunk, 0, 0, RANDOM_WRITE); } } random_harvest_interval() only accepts RANDOM_FIFO_MAX writes into a given FIFO: /* Entropy harvesting routine. This is supposed to be fast; do * not do anything slow in here! */ static void random_harvest_internal(u_int64_t somecounter, const void *entropy, u_int count, u_int bits, u_int frac, enum esource origin) { struct harvest *event; ... /* Lockless read to avoid lock operations if fifo is full. */ if (harvestfifo[origin].count >= RANDOM_FIFO_MAX) return; mtx_lock_spin(&harvest_mtx); /* * Don't make the harvest queues too big - help to prevent low-grade * entropy swamping */ if (harvestfifo[origin].count < RANDOM_FIFO_MAX) { ... } } RANDOM_FIFO_MAX is 256. This means that a big write(2) of data will only store up to 256 chunks of at most 16 bytes apiece (hence 256 * 16 = 4096). The rest would all be thrown away. You might be able to do more than that if the yarrow thread is running concurrently. However, given the work involved in draining the FIFO, I doubt it could drain the FIFO faster than the write(2) could queue data to it, so I don't expect you would be able to get much more than 4096 bytes used from the one big write into /dev/random. > Thanks, > > Doug > > On 09/04/2012 06:12 PM, RW wrote: > > On Tue, 04 Sep 2012 15:39:34 -0700 > > Doug Barton wrote: > > > >> and given what Yarrow does to > >> obfuscate the internal entropy state I'm not confident that hashing > >> the input is either necessary or desirable. > > > > All of the low-grade entropy should go through sha256. > > > > Anything written into /dev/random is passed by random_yarrow_write() 16 > > Bytes at time into random_harvest_internal() which copies it into a > > buffer and queues it up. If there are 256 buffers queued > > random_harvest_internal() simply returns without doing anything. > > > > The yarrow kernel thread moves all of the entropy queues into a local > > queue, processes that queue and then pauses for 100ms and loops. That > > means that each time around the loop only a maximum of 4096 bytes can > > be processed. Anything after that is discarded. > > > > It seems very likely that /entropy is completely discarded most of the > > time, which means that the first 4096 bytes of " ps -fauxww ; sysctl -a" > > is the only entropy that makes it through to yarrow, and that's > > practically nothing. > > > > On a sufficiently fast system the entropy buffers may still be saturated > > when rc.d/random runs, so in theory they could be lost too. And embedded > > doesn't necessarily imply slow. > > > > I'm not overly concerned about this because anything that doesn't > > generate enough entropy naturally, increasingly tends to have a hardware > > generator, but it's easy to fix it, so it should be fixed. > > > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to "freebsd-security- unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > -- John Baldwin