Date: Thu, 11 Jan 2001 15:00:35 -0800 (PST) From: Doug Barton <DougB@gorean.org> To: Warner Losh <imp@harmony.village.org> Cc: Sheldon Hearn <sheldonh@uunet.co.za>, <markm@freebsd.org>, <freebsd-current@freebsd.org> Subject: entropy bikesheds Message-ID: <Pine.BSF.4.31.0101111441370.11112-100000@dt051n37.san.rr.com> In-Reply-To: <200101112222.f0BMMNs75120@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.31.0101111441370.11112-100000>