Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!netnews.upenn.edu!dsinc!newsfeed.pitt.edu!scramble.lm.com!news.math.psu.edu!chi-news.cic.net!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 22 Feb 1996 00:16:49 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 110
Message-ID: <4ggclh$kbv@park.uvsc.edu>
References: <4er9hp$5ng@orb.direct.ca> <4f9skh$2og@dyson.iquest.net> <4gejrb$ogj@floyd.sw.oz.au>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14816 comp.os.linux.development.system:18580
This article was emailed as well.
In the future, please pick one medium or other so as to avoid
inconveniencing your correspondants. Thanks.
jeremy@suede.sw.oz.au (Jeremy Fitzhardinge) wrote:
> >1) Sync enhances the security of your files following a
> > crash and makes sure that part of one of your files
> > does not end up in someone elses hands.
>
> Actually, I have direct evidence that this is not so (and since we like
> throwing around proofs and proof-like language, take this as disproof
> by counterexample). On a Solaris 2.4/x86 system, I was involved in the
> development of a device driver module. As part of the load process,
> you use a program which updates some files and loads the module. In
> this case, the load module was buggy and immediately crashed the system
> on loading. On reboot, the two files which were modified by the module
> loader had their contents partially swapped.
So you believe that UFS's standard practice is to swap block pointers
between in core inodes, then swap them back before it shuts down?
This makes no sense.
I'm not arguing with what you saw, I'm arguing with your conclusions.
Personally, I'm not certain that the bug that caused the crash did not
cause execution/corruption of code prior to the actual crash.
Also, crashes in kernel code why us old farts type sync every other
command (not to say that you aren't also an old fart; it's just typical
that this never happens).
Finally, the async bug I noted could also be in Solaris, for all I know
(I haven't had access to Solaris source code since leaving Novell/USG,
the former USL, for my present job).
> Due to bogosities in Solaris kernel loading and module management,
> these files are actually read by the kernel as it boots, so the
> correctness of their contents is essential in order to boot. The
> corruption rendered the system unbootable and there was no chance that
> fsck could be run. On rebooting from a good root, fsck fixed the
> corrupted filesystem structrure, but left the swapped contents.
Again, I'm not certain the crash did what you thought. Module
initialization (obviously where the failure is) operates on pointers
that could have been corrupt, or, more likely because of the crashing,
the code itself was bogus.
I simply can't predict the results of executing bogus code. All bets
are off.
> The what-ifs:
>
> - If the inodes had different owners, this would have been a security
> breach.
Especially considering the non-root owners would have had to have access
to proveledged directories not checked for ownership and loaded into
the kernel without regard to their correctness. 8-).
> - If the filesystem had async metadata update, the files would
> be unaffected, since the metadata would have been updated with the
> contents but hadn't been at the time of the crash.
This is false. Using "async" updates means that the data can be updated
whenever the hell the kernel feels like it. There is no guarantee that
the data would have been updated, but there is no guarantee that it
would. not have been.
There is, similarly, no guarantee that the data and the metadata would
be updated at the same time or in the right order.
I seriously doubt, in any case, that the inodes exchanged dirty blocks.
It makes no sense whatsoever.
In any case, if you believe that, then you should always run async, and
not blame me about the recovery after your first crash running that way.
> - If the module installer were written properly, it should have fully
> fsynced() the modified files (and preferably all filesystems) before
> loading possibly buggy kernel code (this is just a complaint about
> Solaris, and doesn't really have anything to do with filesystems).
Here we definitely agree. I wrote the module code for FreeBSD; though
it is not explicit, the data is synced prior to load. To not sync is
a bug. If one Solaris bug, why not two?
> Perhaps this is just an anti Solaris rant, and its filesystem is not
> a current UFS implementation, but I doubt that.
I don't. It is likely that they still have the dir.c bug.
If you read the McKusick FFS paper and the McKusick/Kowalski FSCK paper,
you'll see that there is no race condition possible (in a correct UFS
implementation) that could cause what you saw.
I *must* assume that the Solaris implementation does not conform to
the McKusick design document.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.