Date: Thu, 06 Sep 2012 09:39:24 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: obrien@FreeBSD.ORG Cc: Arthur Mesh <arthurmesh@gmail.com>, freebsd-security@FreeBSD.ORG, Doug Barton <dougb@FreeBSD.ORG>, freebsd-rc@FreeBSD.ORG, Mark Murray <markm@FreeBSD.ORG> Subject: Re: svn commit: r239598 - head/etc/rc.d Message-ID: <1346945964.59094.147.camel@revolution.hippie.lan> In-Reply-To: <20120905204050.GB820@dragon.NUXI.org> 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> <20120905204050.GB820@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2012-09-05 at 13:40 -0700, David O'Brien wrote:
> On Tue, Sep 04, 2012 at 02:15:17PM -0600, Ian Lepore wrote:
> > pscmd="ps -fauxrH -o nwchan,nivcsw,nvcsw,time,re,sl"
>
> I do like the changes that this gives over 'ps -fauxww'.
>
> root 11 80.6 0.0 0 32 - RL 8:40AM 0:03.09 [idle] - 1078 1495 0:03.09 8 8
> root 11 42.8 0.0 0 32 - RL 8:40AM 0:04.23 [idle] - 1401 1012 0:04.23 8 8
> root 5 21.6 0.0 0 16 - DL 8:40AM 0:02.17 [xpt_thrd] ffffffff811931e0 104 1 0:02.17 8 4
>
> -vs-
> root 11 121.9 0.0 0 32 - RL 8:40AM 0:06.48 [idle]
> root 5 21.6 0.0 0 16 - DL 8:40AM 0:00.00 [xpt_thrd]
>
Yes, and a significant point is that the extra numbers at the end of
each line tend to be different from one boot to the next on the same
unit.
That can be significant for an embedded system with no writable storage.
There is no saved entropy, there is nothing unique about one unit
compared to another in terms of looking at its configuration (dmesg,
sysctl -a, whatever).
On a system like that you've got to root out the little bit of
real-world entropy available -- things like oscillators whose frequency
varies with temperature just enough to change the timing of something by
a few nanoseconds from one boot sequence to the next. From that, if
you're lucky, you get a bit of butterfly effect that causes the
processes listed by ps to appear in a different order because this time
one of them got a few more cycles before an interrupt caused the
scheduler to switch to some other process, and the process stats will be
a little different as well.
>
> > 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.
>
> I've found that 'sysctl -a' can generate ~270K of output with very little
> of it differing between runs. I've checked the output across reboots at
> the point that 'initrandom' runs.
>
> I've found
> sysctl kern.cp_times kern.cp_time kern.geom kern.lastpid \
> kern.timecounter kern.tty_nout kern.tty_nin vm vfs debug dev.cpu
> to concentrate the changes across reboots. However, I have not tested
> this on ARM or MIPS to ensure these MIB's exist.
>
> Just to double check, you're saying the 3 seconds was for
> 'sysctl -a > /dev/null' vs. feeding that amount of input into
> /dev/random?
>
Yeah, it was just the time to generate the output and feed it
to /dev/null -- the zillion syscalls and all the text formatting eat up
the time.
I don't have one of those super-low-end systems available for testing
right now, but a similar system (bit faster cpu and memory) is showing a
fairly repeatable 0.80s for sysctl -a >/dev/null, and 0.30s for the oids
you listed above.
Of those oids you listed above, the vm and vfs generate a lot of text
but it's mostly the vm.stats part that changes. The kern.geom output is
pretty static on a given system, and oddly it takes a long time to
generate compared to other oids. The cp_time is already included in
cp_times. The dev.cpu is intel-specific.
0.30s - Your list above
0.18s - Your list minus kern.cp_time and vfs, changing vm to vm.stats
0.05s - Also remove kern.geom
I wasn't super-formal with timing, it was just "time
sysctl ...>/dev/null" run by hand several times to ensure that the
numbers weren't varying by more than .02 or so from one run to the next.
So, to reiterate, this is the set of oids that takes only .05s:
kern.cp_times kern.lastpid kern.timecounter kern.tty_nout
kern.tty_nin vm.stats
>
> > 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 would use "tr -Cd '0123456789xabcdef'" since many of the numbers are
> in hex, and would restrict to just the sysctl output. But otherwise I
> like this idea.
>
My gut told me that feeding in just the parts that change the most and
stripping out the boilerplate made sense, but in cryptography what seems
like common sense isn't always correct. Given what Peter reported
earlier about the /dev/random device discarding input if you feed it too
much too fast, extracting 5-6K of changing numbers from the ~100K of
boilerplate might have been a good idea. On the other hand, that also
reduces the input character set to just 10-16 bytes, that's the kind of
thing that makes me think "gut feelings" can be misleading.
Oh, another point worth noting is that on ARM (and possibly MIPS)
systems, forking and execing is particularly expensive (lots of virtual
memory bookkeeping overhead), so part of what I was trying to do was run
just 2 or 3 commands rather than 6-10 commands to generate the output.
Changes to /bin/sh earlier this year to use vfork() have helped reduce
the cost of running multiple commands.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1346945964.59094.147.camel>