Re: Why INVARIANTS option and sanity checking?

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_at_freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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.