From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 15:39:42 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 B8F731065749; Thu, 6 Sep 2012 15:39:42 +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 389EC8FC20; Thu, 6 Sep 2012 15:39:35 +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 q86FdSkk000924; Thu, 6 Sep 2012 09:39:35 -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 q86FdOsD043870; Thu, 6 Sep 2012 09:39:24 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: obrien@FreeBSD.ORG 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> Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Sep 2012 09:39:24 -0600 Message-ID: <1346945964.59094.147.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: Thu, 06 Sep 2012 16:17:18 +0000 Cc: Arthur Mesh , freebsd-security@FreeBSD.ORG, Doug Barton , freebsd-rc@FreeBSD.ORG, Mark Murray 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: Thu, 06 Sep 2012 15:39:42 -0000 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