Date: Mon, 10 Sep 2012 11:40:58 -0700 From: Doug Barton <dougb@FreeBSD.org> To: obrien@freebsd.org Cc: Arthur Mesh <arthurmesh@gmail.com>, freebsd-rc@freebsd.org, Xin Li <delphij@delphij.net>, freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com>, Mark Murray <markm@freebsd.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <504E343A.4020802@FreeBSD.org> In-Reply-To: <20120910135218.GA68128@dragon.NUXI.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
I am opposed to this patch, more details below. On 9/10/2012 6:52 AM, David O'Brien wrote: > On Fri, Sep 07, 2012 at 11:51:57AM +1000, Peter Jeremy wrote: >> I've done some experiments on a couple of systems to look at gzip and >> sha256 speed. On one box, "sysctl -an" returns 109989 bytes (though >> it has been up for a while) which gzip's to 12511 bytes (still too >> large for a single write to /dev/random). The following is the >> wallclock time to run sha256 or gzip on that input (based on multiple >> runs of 100 loops). >> sha256 gzip -6 CPU >> 3.3ms 5.9ms 2.5GHz amd64 (Athlon 4850e) >> 6.8ms 13.3ms 1.6GHz i386 (Atom N270) >> 85 ms 34 ms 700MHz ARMv6 (Raspberry PI, running Linux) >> These times are all in the noise compared to overall startup time. > > I got my slowest times on a CAVIUM OCTEON 52XX CPU Rev. 0.8 with no FPU. > This is the source of my performance concerns. I agree your times are > "in the noise" and thus feel this diff deals with most of the concerns. > > * Updates the comment about blocking -- it hasn't been true for 8 years. Just because .seeded=1 doesn't mean the device is ready to spit out high quality random bits. I don't mind a change in terminology here, but we should be clear that the device needs seeding early. > * Document the natural limitations of the harvesting subsystem due to > it having finite resources (space & time). It has yet to be proven that we're dropping entropy at all. The use of dd to feed the entropy in with 2k chunks is specifically to address this issue. And even if that were not the case, as long as the input keeps flowing past the 100 ms time to empty the buffers we're still pumping entropy into the pools. 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. > * Apply Bruce Schneier's advice WRT not reusing seed material to > the 'better_than_nothing' seed material and only use it on first > post-installation boot. This is also entirely the wrong approach. We should choose commands that have the highest degree of entropy possible between reboots, AND use the /entropy file. I also agree with des' concerns regarding the specific commands you are suggesting that we substitute. Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?504E343A.4020802>