From owner-cvs-all Sat Jan 13 7: 3:38 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id CC9E037B401; Sat, 13 Jan 2001 07:03:16 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f0DF2a721597; Sat, 13 Jan 2001 10:02:40 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 13 Jan 2001 10:02:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mark Murray Cc: Warner Losh , Matt Dillon , 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 In-Reply-To: <200101130754.f0D7s2I19423@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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