Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Sep 2012 15:59:45 -0700
From:      Doug Barton <dougb@FreeBSD.org>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        Arthur Mesh <arthurmesh@gmail.com>, freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray <markm@FreeBSD.org>, "David E. O'Brien" <obrien@FreeBSD.org>
Subject:   Re: svn commit: r239598 - head/etc/rc.d
Message-ID:  <504687E1.3060203@FreeBSD.org>
In-Reply-To: <1346789717.1140.675.camel@revolution.hippie.lan>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?504687E1.3060203>