Date: Thu, 29 Aug 1996 10:04:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rnordier@iafrica.com (Robert Nordier) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: Determining disk type & size Message-ID: <199608291704.KAA28904@phaeton.artisoft.com> In-Reply-To: <199608290019.CAA00356@eac.iafrica.com> from "Robert Nordier" at Aug 29, 96 02:19:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> The notes are useful, Terry, thanks. I think I get the picture, > though I've also saved them to mull over. > > If it wasn't for deviant MS-DOS behavior that needs providing for > in vfat_mountfs(), there wouldn't be a problem with ignoring the > disk type. > > Unfortunately, DOS makes an absolute distinction between hard and > floppy disks in its mount code, to the extent of having entirely > separate routines. These deal differently with boot sector > recognition; validation to determine whether the boot sector BPB > is to be trusted; and even the loading of FS parameters from a > valid boot sector BPB. Try building a hard disk partition exactly a floppy disk size large; if you can get your sector translation to allow it, I think you will be very surprised. I think the main distinction is "is there a partition table on this ting, or isn't there?"... the actual fact that you only allow partition tables on hard disks is irrelevant. I have a hard time with any fix that doesn't use the partition type hints: "this logical device is a child of the 'DOS partitioning' logigical-to-physical device, therefore itis a hard disk". Mostly this is a problem because I don't want to distinguish floppy disks on anything other than the fact that they are removable media. The controls you put in to prevent DOS parititioning of anything but raw devices which are not floppy-disk-sized is entire independent, I think, of the FS implementation itself. Internally, the FS might be expected to get information about its host device. If you want to get into implementation details, the logical-to-physical device mapping probably depends upon this: the "file system" "mount" of a DOS partition to export an Extended DOS partition device, for instance, can be though of in terms of FS stacking, and nothing else. The problem with implementing it exactly this way (yet, anyway) comes from the fact that there is no well-defined "bottom end" interface common to all file systems (again: yet). So the mount code may call a device ioctl() on the device to ask about geometry, and have a table of allowable mount options on that basis. I don't think one of the hints could be, legally, "is floppy disk", without damaging the ability to later abstract media "arrival" and "departure" events. In the *absolute* worst case, consider the floppy disk attached via PCMCIA interface to a laptop. > Of course, one could ignore the whole issue, but this does mean > there are (theoretically) a very great many DOS boot sectors that > would be incompatible. And with the prevalence of boot sector > viruses in the DOS world, there are potentially some practical > implications also. I think they are all required to be taken care of in the "what kind of logical device is allowed to host me" -- one below the level of the implementation, and no deeper. Floppy devices, in this case, will always be raw, and raw devices will only be legal if they are the size of a floppy. The only possible failure case, then would be the raw non-floppy device which only holds up to 2.88M (can you build a floppy DOS FS in 2.88M?). The application of disklabels and/or DOS partitioning should use an ioctl() by root to the host driver to invoke the "format" routine for the logical driver. The interface abstracts the actual implementation, and therefore we end up with a single control program that can operate on all types of partitioning mechanisms -- the holy grail of an install without futzing with 3 or more partitioning-type programs is achieved, and the "write disklabel" and "slice" and "partition" confusion all go away. Open the directory containing the slices on the devfs, and ioctl it to manipulate the slices themselves -- assuming the things are not mounted. > I also just don't like the idea that it is possible to produce > (maliciously) an almost endless supply of different disks that > MS-DOS has no trouble with, but the vfatfs would choke on or corrupt. The MS-DOS "has no trouble" in the examles you have given so far, because it refuses the media. Consider that the logical drivers perform bounds checking on the write requests through them, and we are now saved from the current DOS FS, which trashes the partition following it, in writing out the number of clusters it things should be there. It is the fact that the raw device is being accessed directly, and the bounds checking is in the flawed FS operating from flawed data that causes the corruption of the next FS on the device. Saving the disk image from corruption within the legal bounds -- well, that's another problem. It means restricting what device the FS will allow itself to mount. We already have to distiguish raw+size for FS layout policy anyway (as you pointed out). > I'd even settle for ignoring disk type in the FS, but there's also > an fsck utility that needs to be able to diagnose this stuff. The fsck wants to be an invokable procedure in the VFSOPS array, actually. This allows it to suspen operations, flush buffers, and perform a check successfully, even when the thing is mounted. The allowable corruption semantics in a framework that supports soft updates is much smaller, easily put into the mount code, actually, for FFS (it means making sure the cylinder group offsets are valid, nothing more). Checking the DOSFS external to the DOSFS itself is probably best done at a partition level in any case -- at the same level mounts are done, and at the same level which fsck for FFS happens now. Since the check is by device, it can apply the same "rawness" criteria to the devices as the FS applies. Ideally, this would be shared code, and the call interface to retrieve the information would be abstracted to hide the kernel space/user space nature. I don't think the "hey! this hard disk is a floppy!" problem is really a big fsck problem in any case -- the corruption will be evident and unrecoverable if this (or the reverse) ever happens, anyway. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608291704.KAA28904>