From owner-freebsd-current@FreeBSD.ORG Tue Apr 13 20:10:37 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 B416216A4CE for ; Tue, 13 Apr 2004 20:10:37 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92CBE43D2F for ; Tue, 13 Apr 2004 20:10:37 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.3) with ESMTP id i3E3AIkS004151; Tue, 13 Apr 2004 20:10:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i3E3AIjK004148; Tue, 13 Apr 2004 20:10:18 -0700 Date: Tue, 13 Apr 2004 20:10:17 -0700 From: Brooks Davis To: Chuck Swiger Message-ID: <20040414031017.GA20404@Odin.AC.HMC.Edu> 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> <407C9B07.9070108@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <407C9B07.9070108@mac.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu 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 03:10:38 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 13, 2004 at 09:59:35PM -0400, Chuck Swiger wrote: > >>Anyway, if /etc/rc.d/initdiskless is available, you've got a root=20 > >>filesystem to read from, so can't one nudge the diskless client's=20 > >>/dev/random using entropy from a file stored on it? > > > >You can use a file at this point, but what file should you use? >=20 > I would choose a file that software like OpenSSL, OpenSSH, GnuPG, the EGD= ,=20 > would expect to read entropy from, preferably by default. When we also= =20 > need to consider the context of diskless booting where only a minimal roo= t=20 > filesystem is mounted, it seems /etc/entropy is reasonable. Those programs mostly hope /dev/random works. EGD provides a fake /dev/random based on things like ps output. > >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. >=20 > Starting all of your hosts with the same entropy is a bad idea, agreed. >=20 > I would say that doing something which lets the hosts start rather than= =20 > hang is better than not having a host start up at all. But I think one c= an=20 > do better than use the same entropy for all clients, which is what my nex= t=20 > suggestion was about: >=20 > >>Or perhaps the /usr/share/examples/diskless/clone_root script could=20 > >>call mknod to create a clone of the server's /dev/random device under= =20 > >>the diskless root directory, to provide different "real" entropy for=20 > >>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. >=20 > Excuse me, one used to use mknod to create named pipes. Under FreeBSD it= 's=20 > now mkfifo. Maybe a diff would explain what I mean better: >=20 > --- 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 > } I forgot about that use since I rairly use that feature, but see below. > ...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=3D/etc/entropy of=3D/dev/random bs=3D512 count=3D1 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. This won't work. A named pipe is only usable on the local machine much like a device node. The filesystem is bairly involved in the process. As Mark points out, in many environments, this would be a bad idea even if it worked because it would be easily sniffable. > >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. >=20 > Perhaps it might be useful to have a sysctl for whether /dev/random block= s=20 > or whether it switches from providing "true" entropy to providing=20 > cryptographicly strong random numbers generated by a decent PRNG seeded b= y=20 > or otherwise merged with what "true" entropy is available. [aka=20 > /dev/urandom] We've got that already, it's just implemented by dumping junk into /dev/random and hoping it's good enough like is currently done in initrandom. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAfKuZXY6L6fI4GtQRAibvAJ9cneHuI4HwwTLuZG4er5J/A2UTngCfcWI3 LAMCoZkjruxoaiUP5aZryXE= =0TC3 -----END PGP SIGNATURE----- --DocE+STaALJfprDB--