From owner-freebsd-fs@FreeBSD.ORG Sat Jul 17 01:54:34 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C81B016A4CE for ; Sat, 17 Jul 2004 01:54:34 +0000 (GMT) Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 704B443D1F for ; Sat, 17 Jul 2004 01:54:33 +0000 (GMT) (envelope-from kreil@ebi.ac.uk) Received: from puffin.ebi.ac.uk (puffin.ebi.ac.uk [193.62.196.89]) by maui.ebi.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id i6H1sUF10035; Sat, 17 Jul 2004 02:54:30 +0100 (BST) Received: from puffin.ebi.ac.uk (kreil@localhost) by puffin.ebi.ac.uk (8.11.6/8.11.6) with ESMTP id i6H1sTm14158; Sat, 17 Jul 2004 02:54:30 +0100 Message-Id: <200407170154.i6H1sTm14158@puffin.ebi.ac.uk> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Brooks Davis In-Reply-To: Your message of "Thu, 15 Jul 2004 21:51:35 PDT." <20040716045134.GA28777@Odin.AC.HMC.Edu> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Jul 2004 02:54:29 +0100 From: David Kreil X-EBI-Information: This email is scanned using www.mailscanner.info. X-EBI: Found to be clean X-EBI-SpamCheck: not spam, SpamAssassin (score=-8, required 5, HABEAS_SWE -8.00) cc: freebsd-fs@freebsd.org cc: David Kreil Subject: Re: "sanitizing" disks: wiping swap, non-allocated space, and file-tails X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2004 01:54:35 -0000 Dear Brooks, Many thanks for your fast and helpful reply! > [Please don't cross post so much.] I'm sorry. I had sent it to "ports" two weeks ago, assuming that external programs might be required and then didn't quite know where to turn next. I guess I should have tried individual groups at a time. > The only way to clean a file system I can think of is, to dump the fs, > scrub the disk, restore the fs. That will keep only real data and > remove all the junk. Ok, I can do that once to start from a clean slate but it would not be practical to do this regularly. > You should be able to scrub swap at shutdown if > you use swapoff to disable it, but you've got to be sure it's all unused > first. You can't trust this though because you don't know the system > will shut down cleanly. > > There is a currently null operation in the disk code that acts when > a block is no longer used. It should be possible to hook into that > code to implement some sort of scrubber. It wouldn't be reliable for > the same reason that a swap scrubber can't be, but it would be OK most > of the time. Yes, both approaches would already improve my situation considerably. The handbook says that a shutdown "will attempt to run the script /etc/rc.shutdown, and then proceed to send all processes the TERM signal, and subsequently the KILL signal to any that do not terminate timely". Would turning off swap and scrubbing in rc.shutdown be sufficient, or do I need a way of doing this *after* all other processes have been terminated (and if so, what would be a good approach)? You mentioned the possibility of hooking a scrub routine into the fs code that releases a block. My main worry with such an approach would be that repeated random writes of an individual block would probably never really be written to disk due to drive caching etc. Is there a way around this problem? > The easiest way to scrub a disk is: > > dd if=3D/dev/random of=3D/dev/ bs=3D > > dd if=3D/dev/zero of=3D/dev/ bs=3D > > This doesn't meet DoD requirements, but only for obsolete reasons. Interesting - can you say what type of reasons these are? :-) > > (2) Related to this: > > I'm also interested in people's personal experiences in using partition > > or file system encryption options. > > For performance reasons I'd rather avoid having /tmp and swap and certain= > > work space on an encrypted disk, hence the need for (1). > > If you swap, your performance will be suck enough that encrypting it > won't hurt much, especially with modern CPUs. I wouldn't worry at all > about that cost. /tmp is probably similar for most applications. Really? A loss in disk performance of factor of four should be noticable I had thought. Ah well, since Allan Fields and you seem to agree on this I suppose I should try to dump/restore my system to a gbde partition. With many thanks again for your help and best regards, David. ------------------------------------------------------------------------ Dr David Philip Kreil ("`-''-/").___..--''"`-._ Research Fellow `6_ 6 ) `-. ( ).`-.__.`) University of Cambridge (_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-'