Date: Sat, 13 Jan 2001 10:02:36 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Mark Murray <mark@grondar.za> Cc: Warner Losh <imp@harmony.village.org>, Matt Dillon <dillon@earth.backplane.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh Message-ID: <Pine.NEB.3.96L.1010113095651.21474B-100000@fledge.watson.org> In-Reply-To: <200101130754.f0D7s2I19423@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark, I seems to me that perhaps part of the problem is the /dev/random interface. I'm not very familiar with it, but it seems like a couple of basic primitives might address a lot of the problems: Ways to get and set the current "randomness qualiy" with appropriate privilege. The system boots with low, and later trips to high. Programs requiring crypto-quality randomness can query, and optionally block on real randomness. Calls to srandomdev() could optionally specify the level of randomness required. (DEVRANDOM_LEVEL_CRYPTO or DEVRANDOM_LEVEL_NONCRYPTO). Similarly, a way to specify whether data being spat into /dev/random is of quality or not (I know that it's possible to do this in the kernel API, but not sure about userland). At boot, /dev/random would configure itself at DEVRANDOM_LEVEL_NONCRYPTO, and start using hardware to gather crypto-quality randomness. When init starts up, it identifies sources of weak randomness or at least some junk, and spits it into /dev/random, noting that it is NONCRYPTO randomness. Utilities during boot know to identify their needs: sshd needs real randomness, but mount_mfs doesn't. When the boot gets high enough, init or rc stuffs entropy files in, marked as high randomness (if hardware has already pushed entropy high enough, that's not necessary, but this is in case it hasn't). I.e., part of the problem is an insufficiently flexible API to allow the system to monitor and report randomness quality to userland, and an inability for userland to submit and request the type of entropy needed or provided. I could be off-base here, as I know Yarrow is intended to provide these, I'm just not sure it's exposed. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010113095651.21474B-100000>