From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:59:46 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 683B5106564A; Tue, 4 Sep 2012 22:59:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0A83214E175; Tue, 4 Sep 2012 22:59:46 +0000 (UTC) Message-ID: <504687E1.3060203@FreeBSD.org> Date: Tue, 04 Sep 2012 15:59:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Lepore References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> In-Reply-To: <1346789717.1140.675.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 22:59:46 -0000 On 09/04/2012 01:15 PM, Ian Lepore wrote: > 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. Bummer. > 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". Ok, it should be pretty easy for me to produce that. > 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'" Excellent, thanks! > 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. With the appropriate amount of >/dev/null involved we can still use that if it's available. Given how common the "one big partition" scheme is nowadays I don't object to trying stuff that's in /usr/ as long as we fail softly if it doesn't exist. Particularly in a case like this where it is likely to be useful. > 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. Good info, thanks. > 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. You kids with your fancy ps commands. :) The original version of this was done almost 12 years ago, so I was somewhat limited in what I had available, and even today we are still limited by what's available on all platforms. But I'm glad to see the interest in modernizing this, especially taking embedded systems into better account. > 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. I'm not sure I agree with that, since the combination of lower quality input (the boilerplate) and higher quality (changing numbers) still provides more bits to stir the pool with. Even though the average quality is lower over the total number of bits I still think it's probably more valuable to pump in the higher quantity given the internal chewing that Yarrow does with the bits. Doug