From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 01:28:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A9AD16A41F; Fri, 4 Nov 2005 01:28:14 +0000 (GMT) (envelope-from nocool@263.net) Received: from smtp.263.net (smtp.x263.net [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 007B843D46; Fri, 4 Nov 2005 01:28:11 +0000 (GMT) (envelope-from nocool@263.net) Received: from iscas-zfw728iit (smtp1 [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 04472B28; Fri, 4 Nov 2005 09:28:09 +0800 (CST) (envelope-from nocool@263.net) X-Originating-IP: [159.226.5.225] Date: Fri, 4 Nov 2005 09:28:52 +0800 From: "nocool" To: "Robert Watson" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20051104012809.04472B28@smtp.263.net> Cc: freebsd-current , freebsd-hacker Subject: Re: Why INVARIANTS option and sanity checking? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 01:28:14 -0000 Thanks for your answer. On Wed, 2 Nov 2005, Watson wrote: >There are a number of debugging kernel options available in the kernel, >... >analysis, is configurable to either generate a warning with debugging >trace, or to panic, depending on desired usage. >... >Basically, it all comes down to this: invariants and sanity checking allow >programmers to test that their assumptions about the source code they (or >someone else) has implemented. This helps find bugs faster, and in a way >that makes them much easier to debug. > >Robert N M Watson >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > In my apprehension, these debugging options aim to help developers detect and locate program's error or exception. In view of efficiency and usability, will be turned off in release. That is to say, these option will not be used to resist intrusion. Part of my work is to review the object reuse protection of FreeBSD 5.4 release. Object reuse come from the Trusted Computer System Evaluation Criteria as "The reassignment to some subject of a storage medium (e.g., page frame, disk sector, magnetic tape) that contained one or more objects. To be securely reassigned, no residual data can be available to the new subject through standard system mechanisms." In review object reuse, should we take kernel area memory management into account? To clean the kernel memory during reassignment using vm_page_alloc and ctor or dtor and set up MEMGUARD to insulate the memory between freeing and reallocating? Thank again.