From owner-freebsd-fs@FreeBSD.ORG Tue Jul 20 20:03:21 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 4429516A4CE for ; Tue, 20 Jul 2004 20:03:21 +0000 (GMT) Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3338843D48 for ; Tue, 20 Jul 2004 20:03:20 +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 i6KK3FF28733; Tue, 20 Jul 2004 21:03:15 +0100 (BST) Received: from puffin.ebi.ac.uk (kreil@localhost) by puffin.ebi.ac.uk (8.11.6/8.11.6) with ESMTP id i6KK3Et20000; Tue, 20 Jul 2004 21:03:15 +0100 Message-Id: <200407202003.i6KK3Et20000@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 "Mon, 19 Jul 2004 09:43:34 PDT." <20040719164334.GA14144@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2004 21:03:14 +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: Tue, 20 Jul 2004 20:03:21 -0000 Dear Brooks, Thank you very much again for your comments. > > 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)? > = > I believe you would need to hook after process shutdown unless you're > 100% sure you won't be using swap since you can't disable swap if it's > in use. Ok, so if I do it after the processes' shutdown, any remaining stuff in = virtual memory should easily fit into physical memory. swapoff would then= move = any swapped out pages back to physical memory before disconnecting swap a= nd I = can proceed. Would you know how I could hook into the shutdown procedure *after* the = processes have been terminated? > > 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? > = > With ATA disks, you can disable write caching which should work. With > SCSI disks, you could force each block to disk individualy, in the > correct order. That sounds like coding it would require more disk interface knowledge th= an I = have :-/ > > > The easiest way to scrub a disk is: > > > > > > dd if=3D/dev/random of=3D/dev/ bs=3D > > > I noticed that it will refuse to let me do that on swap, even if it is of= f. Of = course, I can edit the disklabel to read "unused", run dd, and restore th= e = swap disklabel to "swap" but is there another way? Also, I've just done some tests, and dd if=3D/dev/random of=3D/dev/ bs=3D1048576 only writes at 6.5MB/s on my system (/dev/zero gives 7.9MB/s). Is that = typical? My drives theoretically should do 30-40MB/s on read, and 20-30MB= /s on = write. If these results are "normal", however, that means, for a 10GB swap file = and, = say 6 wipes, I'd be waiting 3h on shutdown, while a BND-safe thorough 20 = wipes = would take half a day. Not really practical :-/ So unless you tell me that I should be able to achieve much faster write = speeds, I think I'll have to ditch the idea of regularly wiping swap (or = anything else for that matter). > > > This doesn't meet DoD requirements, but only for obsolete reasons. > > > > Interesting - can you say what type of reasons these are? :-) > = > The short form is that the DoD requirements require writing a pattern, = a > bit flipped version of the pattern, and the pattern again followed by > some set of characters, usually zeros. Unfortunaly, this method was > designed for an encoding technique that has not been used in >20 years > so it doens't work. Ah, ok! Thanks for the pointers :) > > > If you swap, your performance will be suck enough that encrypting i= t > > > 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. > = > For swap, I don't think a factor of four will be noticable since that > just makes accessing swap 4000 times slower then accessing RAM instead > of 1000 times slower (example numbers of course). For file systems, > it's going to depend heavily on your application. Many of them just > don't use that much disk. I believe phk said buildworld wasn't all tha= t > much worse then before (I don't recall an actual number). That's impressive. Ok, I get the impression that in practice having every= thing that's not dedicated fast'n'dirty work-space gbde encrypted might a= fter all be the best solution. With many thanks again for your help, 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),' ((!.-'