Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Sep 2012 09:44:37 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-security@freebsd.org
Cc:        RW <rwmaillists@googlemail.com>, Doug Barton <dougb@freebsd.org>
Subject:   Re: svn commit: r239598 - head/etc/rc.d
Message-ID:  <201209050944.38042.jhb@freebsd.org>
In-Reply-To: <5046D7F0.1000601@FreeBSD.org>
References:  <201208222337.q7MNbORo017642@svn.freebsd.org> <20120905021248.5a17ace9@gumby.homeunix.com> <5046D7F0.1000601@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209050944.38042.jhb>