Date: Sat, 6 Apr 1996 10:19:17 +0200 (MET DST) From: grog@lemis.de (Greg Lehey) To: terry@lambert.org (Terry Lambert) Cc: franky@pinewood.nl, freebsd-current@FreeBSD.org Subject: Re: 2.2-960323 Panic in mount_msdos Message-ID: <199604060819.KAA07652@allegro.lemis.de> In-Reply-To: <199604042010.NAA22425@phaeton.artisoft.com> from "Terry Lambert" at Apr 4, 96 01:10:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > >> I know you cannot mount an NTFS under FreeBSD, but at least the system >> should not crash. Agreed. >> I just report this problem as I have too little knowledge of the internals >> of the kernel to fix the problem myself :-) > > A file system operates by copying on disk strucutures into memory > and then using the offsets in the coppy to access additional memory. > > It does not bounds-check these accesses. > > If there is a problem with this, it's that the DOSFS did not validate > that the device was in fact a DOS partition before going gung-ho into > dereferencing. > > Not bounds-checking dereferences isn't an error; it an optimization, > and it's allowable because mount is not a user accessable command > (you have to be root). If not bound-checking causes a crash, then in my book it's an error. Sure, you shouldn't be able to mount incorrect file systems, but even if the file system is correct, there's always the chance of data corruption. I agree that it's not a good idea to be paranoid about every pointer, but there should be a way to recover if the data is corrupted. Typically, that's done by bounds checking such pointers. Maybe it would be interesting to put drivers like this at IOPL1, where they could be recognized as such and, if found wanting, terminated rather than crashing the system. > The fix for inconsistent media is to run fsck (or equivalent) on it > before attempting a mount; the fix is procedural, in other words, > and doesn't require a change to the mount code. Yes, but this isn't sufficient. It also places the onus on the user. I still believe that the kernel should protect itself as much as possible from outside influences. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604060819.KAA07652>