Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Dec 2009 13:51:44 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        RW <rwmaillists@googlemail.com>
Cc:        freebsd-hackers@freebsd.org, markm@FreeBSD.org
Subject:   Re: yarrow random generator
Message-ID:  <alpine.BSF.2.00.0912251345230.73550@fledge.watson.org>
In-Reply-To: <20091224231334.2e242371@gumby.homeunix.com>
References:  <5a5b03660912240445x7df1498dt42e29d93105efebc@mail.gmail.com> <oCmohG1K70vWpt/39IVPMdciTgk@DNdB9ElzNmEFYWRqT2UTVtuts%2BE> <4B339F27.6020707@freebsd.org> <5a5b03660912240941r6b76a839u819a8a1408816386@mail.gmail.com> <alpine.BSF.2.00.0912241945490.73550@fledge.watson.org> <20091224231334.2e242371@gumby.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 24 Dec 2009, RW wrote:

>>> And also according to Schneier it is a good idea to save state of the PRNG 
>>> and restore it on boot to make it "more seeded".
>>
>> In the default configuration, we save some PRNG output every few minutes 
>> (using cron) to a file in /var so that it can be re-injected into Yarrow on 
>> the next boot (done by /etc/rc.d/random).
>
> It isn't handled very well though. The files saved by crontab under /var are 
> loaded a bit late in the boot sequence - after encrypted swap.
>
> The main entropy file is loaded earlier, but immediatly after ps -fauxww, 
> sysctl -a, etc are dumped into the device, saturating its 4K of buffer 
> space.

I can't speak to the specific /dev/random design choices here, but I can say 
that there is a more general issue with swap being required to get to the 
point where you reliably have writable file system access.  This is because 
fsck can be quite memory-heavy, and so swap is started before fsck is started. 
It could well be that the arrival of proper UFS journaling support in the 
immediate future allows more agressive reordering of the boot process so that 
writable file systems can be assumed much earlier.

I'll point Mark Murray at this thread and see if we can get him to opine some 
on the current design choices and any potential changes to address them.  I 
was interested by your observation that the boot-time dumping of bits into 
/dev/random may overflow the buffering -- indeed, it looks like the 
rate-controlling in effect for other entropy sources may not be appropriate 
for /dev/random.

Robert N M Watson
Computer Laboratory
University of Cambridge



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