From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 20:15:21 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D0461065673; Tue, 4 Sep 2012 20:15:21 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C894A8FC19; Tue, 4 Sep 2012 20:15:20 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q84KFJ9Y062280; Tue, 4 Sep 2012 14:15:20 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q84KFHIh041559; Tue, 4 Sep 2012 14:15:17 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Doug Barton In-Reply-To: <50451041.9070302@FreeBSD.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Sep 2012 14:15:17 -0600 Message-ID: <1346789717.1140.675.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 04 Sep 2012 20:39:31 +0000 Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" 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: Tue, 04 Sep 2012 20:15:21 -0000 On Mon, 2012-09-03 at 13:17 -0700, Doug Barton wrote: > On 09/02/2012 19:18, Ian Lepore wrote: > > I have a patchset somewhere that added the ability to supply an > > alternate command to generate "best effort" entropy. The reason is that > > the existing code on an embedded system with no realtime clock hardware > > generates a sequence that sometimes differs by two full bytes from one > > boot to the next. Often it's identical. Adding insult is the fact that > > the existing sequence takes about 4-5 seconds on that platform. > > > > There just isn't much entropy available there, but I came up with a > > command sequence that ran in about a second and generated more > > differences on each boot. > > I'm interested in that patch. Alas, I cannot find the patch itself, just some old notes. It's no great loss... as I remember it the code part was pretty dumb, it just looked for a variable with a name like initrandom_entropy_cmd, and if that variable was not empty it did "eval $initrandom_entropy_cmd" and nothing else; the command itself had to generate data and feed it to /dev/random. In other words, the mechanism was basically "you want control? you've got it". I'm not sophisticated in the ways of rc fu, so it's unlikely I could come up with the best solution, and I'd be happy with anything that would provide more control, whatever the mechanism. I did find some notes that contained the alternative command sequence I was happy with, which was apparently: pscmd="ps -fauxrH -o nwchan,nivcsw,nvcsw,time,re,sl" sccmd="sysctl kern.timecounter.tc kern.cp_times vm.stats" vmcmd="vmstat -Pismz" entropy_cmd="($vmcmd; $sccmd; $pscmd) | tr -Cd '0123456789'" But I've just now realized that vmstat lives in /usr/bin, which maybe won't be mounted at the time this is needed? If so that's too bad, because that set of vmstat parms generates some numbers that are unlikely to be identical from one boot to the next. The sysctl -a in the original initrandom sequence was part of the killer for execution time. On a 180mhz arm chip that command alone takes like 3 seconds, and it generates a lot of unchanging boilerplate text. I remember picking a few select values that had a good chance of being different from one run to the next. The same is true of the parms I used on the ps command, I asked for outputs like "number of involuntary context switches" because even a small difference in the timing of an interrupt occurring during one boot sequence compared to the next can perturb those numbers. Those commands still generated a fair amount of unchanging boilerplate text, and it's mostly the numbers that change, so I fed all the output through tr to strip out everything but the numbers. -- Ian