From owner-freebsd-security  Thu Nov 18 20:54:48 1999
Delivered-To: freebsd-security@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 02923152BB; Thu, 18 Nov 1999 20:54:44 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id UAA90603;
	Thu, 18 Nov 1999 20:54:43 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 18 Nov 1999 20:54:43 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199911190454.UAA90603@apollo.backplane.com>
To: David G Andersen <danderse@cs.utah.edu>
Cc: barrett@phoenix.aye.net (Barrett Richardson), wes@softweyr.com,
	kris@hub.freebsd.org, trouble@netquick.net, danderse@cs.utah.edu,
	freebsd-security@FreeBSD.ORG
Subject: Re: secure filesystem wiping
References:  <199911190446.VAA22206@faith.cs.utah.edu>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

:Not if you do it right.  Do it in blocks, and use madvise 
:(try MADV_SEQUENTIAL on the whole region, or simply MADV_DONTNEED each
:block after you're done).  I'd wager that MADV_SEQUENTIAL will give you
:exactly the behavior you're looking for if you do something like:
:
:Blocks in terms of pagesize would be particularly appropriate, yes. :)
:...
:  -Dave
:
:-- 

    MADV_SEQUENTIAL will definitely work.  In fact, if you scan the file
    sequentially you do not even need to call madvise(), it will figure it
    out and do the right thing.

    But there is no guarentee that the system will flush the pages to disk
    prior to removal of the file, and removing the file may cancel the
    pending I/O.  Maybe if you msync() the area and then fsync() the file
    prior to closing it.

    I would simply use a write() loop, then fsync() and close() the file
    when done.  For this type of scribbling write() will be much faster
    then mmap().  Don't bother with mmap() at all.

    Both the VFS interface (read and write) and the mmap interface will
    properly handle write-behind and reuse pages without loading the system
    too badly.  Current does a somewhat better job at it due to tuning work
    and a change in the way the file position is cached in regards to 
    determining the file mode.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message