Date: Fri, 12 Jan 2001 00:46:37 -0800 From: Doug Barton <DougB@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: Warner Losh <imp@harmony.village.org>, Mark Murray <mark@grondar.za>, Sheldon Hearn <sheldonh@uunet.co.za>, 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: <3A5EC46D.A912BC6F@FreeBSD.org> References: <200101120644.f0C6hvI12630@gratis.grondar.za> <200101120534.f0C5YYH96390@earth.backplane.com> <200101120652.f0C6qls78578@harmony.village.org> <200101120711.f0C7B4Y97991@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote: > I think it's fairly obvious that we don't need cryptographic > randomness for early boot stages. Since no one seems to actually be reading my posts, let me reiterate something. /etc/rc does the following in the early stages right now: 1. rc.diskless 2. source the /*/rc.conf* files 3. try seeding from /entropy - This would be replaced by Warner's suggestion. 4. ccdconfig 5. vinum start 6. fsck 7. mount root RW (exit if this fails) 8. umount -a 9. mount -a -t nonfs In case I haven't made it clear yet, I would really love to do away with the "gross hacks" that make 3. work, and postpone reading in the "real" entropy seeding till we get past 9. Up till we actually had offers of help today, IT WAS NOT POSSIBLE TO MOUNT -A RELIABLY BECAUSE /DEV/RANDOM WOULD BLOCK. Hopefully that will be the last time I have to say it. Now, are you sure that ccdconfig, vinum, fsck, and mount* (other than nfs) will work with a "weak" amount of randomness? In a previous post today I asked this question and got no response. I welcome any help to get the thing whipped into a shape that we will be proud to ship. But until that happens can we seriously try and remember that this is -current? > All I'm hearing is paranoia (not > from Warner) and all I'm seeing are massive hacks being committed to > the system for no reason at all. The system daemons that require > cryptographic randomness don't start until much, much later in the > boot sequence, long after the filesystems have been mounted. It makes > no sense to construct massive hacks to make the random number generator > cryptographically secure so early in the boot process. You know, your arguments would go across a lot easier without the vitriol. You have been a great help to me in the past Matt, and I don't get my feathers ruffled easily; but you would be well served to at least give us credit for what we're actually trying to accomplish, misguided or not. > It makes even less sense to commit a cron job that runs every > 3 *MINUTES*. I don't care how much or how little it does... it makes > NO SENSE. Apparently it makes sense to Schneier. For the initial commit Mark just gave me something approximating the recommended values. I ran with the stuff for a couple days and never even noticed it. I did start to think however that the 8 seeds would probably really only be useful at boot time, so it might make more sense to run it every 3 minutes for an hour after boot, then every N minutes thereafter. However, I needed to do some research on our new(ish) ability to schedule cron jobs for @boot, or whatever the hell it is. > How can anyone believe that that would fly in a release? How can anyone not pay attention to the first 427 messages saying that our yarrow implementation is still under development and will be much more polished way before 5.0-Release happens? > Now I see two perfectly good solutions here. As stated, Warner's suggestion is a good one, presuming that Mark is satisfied regarding being able to provide sufficient entropy to kickstart yarrow, AND that we're sure none of the things listed above in 4-9 need strong randomness to work. Assuming that all of that is true, moving the reading of /var/db/entropy/* to right after the mount -a is the logical next step. This should (better) put an end to the complaints. As long as it's not needed, I don't think that special casing mfs in mount is really a good idea, personally, but as I've said several times today I'm not a fs expert. Finally, for those who have offered words of encouragement and/or actual help in dealing with the issues involved in making this work, please accept my thanks. Doug 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?3A5EC46D.A912BC6F>