From owner-freebsd-hackers Tue Sep 22 19:40:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04547 for freebsd-hackers-outgoing; Tue, 22 Sep 1998 19:40:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04473 for ; Tue, 22 Sep 1998 19:39:59 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA17353; Tue, 22 Sep 1998 19:39:57 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd017330; Tue Sep 22 19:39:53 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA15572; Tue, 22 Sep 1998 19:39:51 -0700 (MST) From: Terry Lambert Message-Id: <199809230239.TAA15572@usr06.primenet.com> Subject: Re: FYI: function call failures To: tinguely@plains.NoDak.edu (Mark Tinguely) Date: Wed, 23 Sep 1998 02:39:51 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199809221907.OAA07181@plains.NoDak.edu> from "Mark Tinguely" at Sep 22, 98 02:07:14 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > *** FYI. for S/N concerns, please take comments about paper to -chat *** > > from comp.arch a reference (http://www.ices.cmu.edu/ballista/ftcs98/) to > a test of function call failures. FreeBSD did not fair too well compared > to other OSes. > > *** FYI. for S/N concerns, please take comments about paper to -chat *** This is not a comment about the paper; it is a comment about your statement that "FreeBSD did not fair too well compared to other OSes". Unfortunately, I'll have to examine the metric you are holding out in order to make my comment. They are counting abort() traps as a result of passing bad pointers to library functions and system calls as "failures". This is because: ...In this scale, the response lies in one of six categories: Catastrophic (the system crashes or hangs), Restart (the test process hangs), Abort (the test process terminates abnormally, i.e. "core dump"), Silent (the test process exits without an error code, but one should have been returned), Hindering (the test process exits with an error code not relevent to to the situation), and Pass (the module exits properly, possibly with an appropriate error code). Silent and Hindering failures are currently not found by Ballista. In other words: o if you SIGSEGV from a NULL pointer dereference, you are a "bad" OS o if you silently accept bogus arguments without crashing or otherwise indicating an error, you are a "good" OS o if you silently accept bogus arguments that should have resulted in an error, but didn't, you are a "good" OS To wit, this is a rehash of the following two long-lived threads: o FreeBSD should check for invalid pointer arguments to functions like strcmp and strcpy, and otherwise engage in idiot-proofing code, even though idiots who will call these functions incorrectly will not recognize an error response when it bites them on the arse. o FreeBSD should never call abort, even when data outside the process virtual address space is referenced, since even though doing so will pinpoint the exact line of code where the problem exists, while at the same time preventing cascade failures (like launching all nukes if a single failure causes one nuke to be launched), we prefer to trust the programmers to always check the strcpy(3) return values, because we know that all programs check for error returns for libc functions (yeah, right). If you can't tell yet, I disagree with your statement about how well FreeBSD did or did not fare. There is a particular, and *desirable* length to that blue bar for a POSIX compliant OS, though they fail to state where that boundary is, unfortunately, and FreeBSD had no catastropic errors, nor any Restart errors. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message