Re: Why INVARIANTS option and sanity checking?

On Fri, 4 Nov 2005, nocool wrote:

> 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.

That is correct.  While some users do run with INVARIANTS turned on in 
production, this is not the recommended configuration for performance 
reasons.  The benefit to running with INVARIANTS on is that, in principle, 
if you do run into a bug, the system may fail stop faster, rather than 
perhaps allowing kernel memory corruption to persist.  I'm not sure this 
is likely in a number of cases (often you get a panic immediately 
afterwards because the invariant is violated), but it does make bugs 
easier to track down.  Because INVARIANTS does perform kernel memory 
scrubbing, it is quite expensive in terms of CPU.

> 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?

The design for FreeBSD calls for all memory and other resources provided 
to unprivileged processes to be scrubbed before being made available. 
Only using privilege should a process be able to gain access to unscrubbed 
resources through allocation.  For example:

- When a process allocates a new file, it will be created as zero-length.
   When extended using ftruncate(), any data read or pages mapped from the
   file will be zero-filled.

- When new memory is allocated to the process at time of exec(), using
   brk(), or using anonymous mmap(), zero'd pages are provided to the
   process (often optimized using copy-on-write).

- When kernel data structures are returned to user space, they are zero'd.
   This is necessary even when a structure is filled out explicitly, as the
   padding in the structure introduced by the compiler must also be zero'd.
   For example, with data structures returned by ioctl(), sysctl(), etc.

When using privilege, it is possible to bypass these protections by 
directly accessing the disk device (allowing reading outside of allocated 
file space), direct access to allocated and unallocated kernel memory 
(/dev/mem, /dev/kmem), direct access to swap devices, and so on.

If you are aware of bugs in the implementation that result in improper 
scrubbing of objects on reuse, please let us know by submitting a bug 
report.  While we do optimize reuse scrubbing in a number of situations 
(copy-on-write from zero'd pages, for example), the semantics should be 
consistent for the user process.  This is especially important with the 
advent of services like IPSEC, where valuable keying material persists in 
the kernel for extended periods.

Robert N M Watson