From owner-freebsd-rc@FreeBSD.ORG Mon Sep 10 13:52:19 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 965FC1065670; Mon, 10 Sep 2012 13:52:19 +0000 (UTC) Date: Mon, 10 Sep 2012 06:52:18 -0700 From: David O'Brien To: Peter Jeremy Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120907015157.GA29497@server.rulingia.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , Doug Barton , freebsd-rc@freebsd.org, Xin Li , freebsd-security@freebsd.org, RW , Mark Murray Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:52:19 -0000 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. * Document the natural limitations of the harvesting subsystem due to it having finite resources (space & time). * Apply above documentation and don't write over 100k to /dev/random thinking it is all processed. [or even the reduced 50k of output from using more selective commands] * 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. Index: initrandom =================================================================== --- initrandom (revision 239610) +++ initrandom (working copy) @@ -18,18 +18,40 @@ feed_dev_random() { if [ -f "${1}" -a -r "${1}" -a -s "${1}" ]; then cat "${1}" | dd of=/dev/random bs=8k 2>/dev/null + else + return 1 fi } better_than_nothing() { - # XXX temporary until we can improve the entropy - # harvesting rate. # Entropy below is not great, but better than nothing. - # This unblocks the generator at startup - ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww ) \ + + # Entropy below is not great, but better than nothing. + # Overwhelming the internal entropy seeding buffers is a NOP. + # Once the internal buffers are filled, additional input is + # dropped on the floor until the buffers are processed. + # For FreeBSD's current yarrow implementation that means + # there is little need to seed with more than 4k of input. + # In order to reduce the size of the seed input we hash it. + + # The output of a cryptographic hash function whose input + # contained 'n' bits of entropy will have 'm' bits of entropy, + # where 'm' is either 'n' or slightly less due to collisions. + # So we operate under the premise that there is essentially + # no loss of entropy in hashing these inputs. + + /sbin/sha256 -q `sysctl -n kern.bootfile` \ | dd of=/dev/random bs=8k 2>/dev/null - cat /bin/ls | dd of=/dev/random bs=8k 2>/dev/null + + # Note: commands are ordered based on least changing across reboots + # to most: + ( dmesg; kenv; df -ib; \ + ps -fauxrH -o nwchan,nivcsw,nvcsw,time,re,sl; \ + sysctl -n kern.cp_times kern.geom kern.lastpid kern.timecounter \ + kern.tty_nout kern.tty_nin vm vfs debug dev.cpu; \ + date ) \ + | /sbin/sha256 -q | dd of=/dev/random bs=8k 2>/dev/null } initrandom_start() @@ -67,16 +89,16 @@ initrandom_start() # case ${entropy_file} in [Nn][Oo] | '') + better_than_nothing ;; *) if [ -w /dev/random ]; then - feed_dev_random "${entropy_file}" + feed_dev_random "${entropy_file}" \ + || better_than_nothing fi ;; esac - better_than_nothing - echo -n ' kickstart' fi -- -- David (obrien@FreeBSD.org)