From owner-freebsd-current@FreeBSD.ORG Tue Apr 13 18:58:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B082B16A4CE for ; Tue, 13 Apr 2004 18:58:07 -0700 (PDT) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FFBA43D45 for ; Tue, 13 Apr 2004 18:58:07 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out012.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040414015806.OIBK18295.out012.verizon.net@mac.com>; Tue, 13 Apr 2004 20:58:06 -0500 Message-ID: <407C9B07.9070108@mac.com> Date: Tue, 13 Apr 2004 21:59:35 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <200404131550.i3DFocIn099231@grimreaper.grondar.org> <428207C0-8D7B-11D8-B697-003065ABFD92@mac.com> <20040413191058.GF20550@Odin.AC.HMC.Edu> <20040413232816.GB25818@Odin.AC.HMC.Edu> In-Reply-To: <20040413232816.GB25818@Odin.AC.HMC.Edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [68.160.247.127] at Tue, 13 Apr 2004 20:58:06 -0500 cc: freebsd-current@freebsd.org Subject: Re: dev/random X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 01:58:07 -0000 Brooks Davis wrote: > Mark and I are discussing some modifications to the rc files to improve > the situation, hopefully we'll have something basic ready to go in the > next 24-hrs or so. Yay! [ ... ] >> Anyway, if /etc/rc.d/initdiskless is available, you've got a root >> filesystem to read from, so can't one nudge the diskless client's >> /dev/random using entropy from a file stored on it? > > You can use a file at this point, but what file should you use? I would choose a file that software like OpenSSL, OpenSSH, GnuPG, the EGD, would expect to read entropy from, preferably by default. When we also need to consider the context of diskless booting where only a minimal root filesystem is mounted, it seems /etc/entropy is reasonable. > You almost certaintly don't have a /var and there's a good change / isn't > writable at all and starting all your hosts with the same entropy is > definatly a bad idea. You also may not have anything in /etc other then > what is provided by make distribution. Starting all of your hosts with the same entropy is a bad idea, agreed. I would say that doing something which lets the hosts start rather than hang is better than not having a host start up at all. But I think one can do better than use the same entropy for all clients, which is what my next suggestion was about: >>Or perhaps the /usr/share/examples/diskless/clone_root script could >>call mknod to create a clone of the server's /dev/random device under >>the diskless root directory, to provide different "real" entropy for >>each diskless client? > > I'm not sure what you're getting at here. /dev is devfs even in single > user so mknod isn't applicable. It's not optional. Excuse me, one used to use mknod to create named pipes. Under FreeBSD it's now mkfifo. Maybe a diff would explain what I mean better: --- clone_root_20040413 Tue Apr 13 21:01:57 2004 +++ clone_root Tue Apr 13 21:08:33 2004 @@ -94,4 +94,6 @@ # (cd $DEST; cpio -i -H newc -d ) echo "+++ Fixing permissions on some objects" chmod 555 $DEST/sbin/init + echo "creating /etc/entropy" + mkfifo ${DEST}/etc/entropy } ...and set up an rc script on the fileserver to do: cat /dev/random > ${DEST}/etc/entropy ...to fill the named pipe with high-quality entropy when and if a client machine reads that file. Hmm, quick testing suggests the cat statement will terminate if too much data is read at a time, maybe "tail -f" instead? Somewhere in /etc/rc.d/initdiskless (or somewhere else appropriate), have client machines do something like: dd if=/etc/entropy of=/dev/random bs=512 count=1 2>/dev/null Even though the client machines are mounting the diskless root read-only, each client that reads /etc/entropy will be getting different bits, ie, they'll be grabbing entropy from the server's random pool to initialize themselves. [ ... ] > To be clear, the problem is not that you can't open /dev/random for > read, it's that read() blocks until sufficent entropy arrives. It's > worth noting that the quality of entropy needed in initdiskless is > pretty minimal. rand() would actually be fine here other then the fact > that use of rand should not be encouraged. Perhaps it might be useful to have a sysctl for whether /dev/random blocks or whether it switches from providing "true" entropy to providing cryptographicly strong random numbers generated by a decent PRNG seeded by or otherwise merged with what "true" entropy is available. [aka /dev/urandom] -- -Chuck