Date: Fri, 10 Nov 1995 14:26:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: terry@lambert.org, lm@slovax.engr.sgi.com, hackers@FreeBSD.org, waa@aurora.cis.upenn.edu, deraadt@theos.com, chuck@maria.wustl.edu Subject: Re: larry: you might want to add this to lmbench (but i'm not sure) Message-ID: <199511102126.OAA04513@phaeton.artisoft.com> In-Reply-To: <Pine.SOL.3.91.951110151539.13530N-100000@morse> from "Ron G. Minnich" at Nov 10, 95 03:26:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511102126.OAA04513>