From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 4 09:19:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 581AD16A41F; Fri, 4 Nov 2005 09:19:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB91643D45; Fri, 4 Nov 2005 09:19:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D94AD46B8D; Fri, 4 Nov 2005 04:19:01 -0500 (EST) Date: Fri, 4 Nov 2005 09:19:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: nocool In-Reply-To: <20051104012809.04472B28@smtp.263.net> Message-ID: <20051104091034.A9692@fledge.watson.org> References: <20051104012809.04472B28@smtp.263.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers , freebsd-current Subject: Re: Why INVARIANTS option and sanity checking? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 09:19:03 -0000 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