Why INVARIANTS option and sanity checking?
rwatson at FreeBSD.org
Fri Nov 4 01:19:03 PST 2005
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
More information about the freebsd-hackers