From owner-freebsd-hackers Fri Nov 10 13:33:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA10985 for hackers-outgoing; Fri, 10 Nov 1995 13:33:55 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA10980 for ; Fri, 10 Nov 1995 13:33:51 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id NAA22355 for ; Fri, 10 Nov 1995 13:33:35 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA04513; Fri, 10 Nov 1995 14:26:58 -0700 From: Terry Lambert Message-Id: <199511102126.OAA04513@phaeton.artisoft.com> Subject: Re: larry: you might want to add this to lmbench (but i'm not sure) To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Fri, 10 Nov 1995 14:26:57 -0700 (MST) Cc: terry@lambert.org, lm@slovax.engr.sgi.com, hackers@FreeBSD.org, waa@aurora.cis.upenn.edu, deraadt@theos.com, chuck@maria.wustl.edu In-Reply-To: from "Ron G. Minnich" at Nov 10, 95 03:26:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2162 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I'd actually hope that programs that got this kind of error would be > > murdered by the OS. Code that didn't check its return values in > > the face of such an error shouldn't be allowed to continue running. > > We tried this program on windows/nt and it got killed. But for an > interesting reason: the posix subsystem on nt is a library, not the > kernel server that the books lead you to believe it is. So the posix > library does a load from the bogus pointer and dies. > > But here's the $9K question: how do you decide it's not checking return > values, and what return values should you require be checked and which > shouldn't? i'm not convinced that's a decision the os should make. Well, you *can't* tell that it's not checking the return values. Unless the return is by way of a signal mechanism, which if it isn't checking, will force image termination. The question is one of the philosophy of when you can get an EFAULT return, what does it mean. When a program does a read(2) or write(2) or whatever and gets this error, the call has been passed a bogus argument. You have to wonder under what expectable operating conditions a bogus argument could possibly be passed, and then recovered from successfully by anything other than a shutdown. A shutdown of the process could be handled equally well by a fault handler. So maybe the cheap answer to the question is you do enforcement wherever doing enforcement is practically free or even less expensive than the alternative. It's actually more expensive to return EFAULT and expect the program to recover than it would be to signal the program. For all intents and purposes, fatal error paths are free. They only ever get executed in the case that the error is unrecoverable. In the read EFAULT case, the system can't recover by putting the data elsewhere, etc.. I'm now really, really interested in what the heck you are doing that passes bogus values to read, but it's programatically OK for it to pass them?!? 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.