From owner-freebsd-current  Sat Apr  6 00:30:31 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id AAA14436
          for current-outgoing; Sat, 6 Apr 1996 00:30:31 -0800 (PST)
Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA14427
          for <freebsd-current@FreeBSD.org>; Sat, 6 Apr 1996 00:30:24 -0800 (PST)
Received: from allegro.lemis.de by diablo.ppp.de with smtp
	(Smail3.1.28.1 #1) id m0u5TO0-000QYLC; Sat, 6 Apr 96 10:30 MET DST
From: grog@lemis.de (Greg Lehey)
Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany
Phone: +49-6637-919123
Fax:   +49-6637-919122
Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) 
	id KAA07652; Sat, 6 Apr 1996 10:19:17 +0200
Message-Id: <199604060819.KAA07652@allegro.lemis.de>
Subject: Re: 2.2-960323 Panic in mount_msdos
To: terry@lambert.org (Terry Lambert)
Date: Sat, 6 Apr 1996 10:19:17 +0200 (MET DST)
Cc: franky@pinewood.nl, freebsd-current@FreeBSD.org
In-Reply-To: <199604042010.NAA22425@phaeton.artisoft.com> from "Terry Lambert" at Apr 4, 96 01:10:04 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

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