From owner-freebsd-current Thu Jan 11 15: 1: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id B806337B400; Thu, 11 Jan 2001 15:00:47 -0800 (PST) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id PAA11651; Thu, 11 Jan 2001 15:00:35 -0800 (PST) (envelope-from DougB@gorean.org) Date: Thu, 11 Jan 2001 15:00:35 -0800 (PST) From: Doug Barton X-X-Sender: To: Warner Losh Cc: Sheldon Hearn , , Subject: entropy bikesheds In-Reply-To: <200101112222.f0BMMNs75120@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Since this post actually has some content I'm moving it to -current. On Thu, 11 Jan 2001, Warner Losh wrote: > I agree. RO / is absoultely *REQUIRED* for our application. As stated, all concerned are sympathetic to that. This is why it's configurable. > we have > a small, writable partition that we can use to store the random > entropy files. Any attempts to force / to be writable will be met > with extreme resistance. The good thing about this ridiculous thread is that the next time someone asks me if I've read the code, I can simply respond with, "No one reads the code for my projects, even when I include the cvsweb links in my head's up mail, so why should I be bothered?" > Our /var isn't persistant accross boots, btw. It is a mfs file > system. Having a requirement that /var contain persistant data would > likely lead to problems. It's precisely for these, and other hairy examples that I haven't put the thing in /var yet. Even a diskless workstation can read files from a RO root that the host writes out periodically, but there is no guarantee that there will be a /var filesystem that we can read from at boot time. I actually started to write some code to handle some obvious cases and got a major headache just thinking about it. > I'm still not sure why we can't do something like: > > date > /dev/random > cat /bin/ls > /dev/random > fsck > mount the file systems > read in the entropy file > > Eg, toss some bone to the random pool. Sure, it will be highly > preditable, but for the mount commands it doesn't matter. We fix > before anything interesting happens. I have a lot of sympathy for this idea, but I don't know if it would work for yarrow. Mark will have to weigh in on it first. FYI, the things rc does first (as needed) are below. / is already mounted RO at this point. 1. rc.diskless 2. source the *rc.conf* files 3. try seeding from /entropy 4. ccdconfig 5. vinum start 6. fsck 7. mount root RW (exit if this fails) 8. umount -a 9. mount -a -t nonfs For my money that's a fairly large number of things that could potentially break if I fooled around with the mount'ing order, so I felt that putting the default in /.entropy was a good way to get started with the minimum amount of real pain. Bikeshed pain I can deal with. One way to deal with this is to introduce a new variable that specifies the filesystem mount point that needs to be mounted to read the seed files. That way we could mount that fs RO, do the seeding, then unmount it and proceed with the rest of the steps from 4. on. I would need some advice on potential pitfalls here though, which is why I haven't acted on it yet. The one that leaps immediately to mind is am I getting myself into trouble by mounting a potentially dirty filesystem, even though it's RO? I know this is done with /, but I'd like someone with more fs experience to confirm that I won't be digging a hole for someone if they have some sort of funky /var/foo fs that I haven't heard of. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message