From owner-freebsd-fs@FreeBSD.ORG Tue Jul 20 22:24:53 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 AAB9A16A4CE for ; Tue, 20 Jul 2004 22:24:53 +0000 (GMT) Received: from maui.ebi.ac.uk (maui.ebi.ac.uk [193.62.196.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC75A43D5F for ; Tue, 20 Jul 2004 22:24:52 +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 i6KMOoF04403; Tue, 20 Jul 2004 23:24:50 +0100 (BST) Received: from puffin.ebi.ac.uk (kreil@localhost) by puffin.ebi.ac.uk (8.11.6/8.11.6) with ESMTP id i6KMOoN05374; Tue, 20 Jul 2004 23:24:50 +0100 Message-Id: <200407202224.i6KMOoN05374@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 "Tue, 20 Jul 2004 15:00:33 PDT." <20040720220033.GA12560@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: Tue, 20 Jul 2004 23:24:50 +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 22:24:53 -0000 Dear Brooks, Thank you very much for your fast reply. > > Would you know how I could hook into the shutdown procedure *after* the > > processes have been terminated? > > Unfortunaly, I don't. I suspect you may have to hack init. Hmpf, ok, will have a look. > > > > > The easiest way to scrub a disk is: > > > > > > > > > > dd if=/dev/random of=/dev/ bs= > > > > > > > > > I noticed that it will refuse to let me do that on swap, even if it is > > off. Of course, I can edit the disklabel to read "unused", run dd, and > > restore the swap disklabel to "swap" but is there another way? > > That's broken. Which OS are you using? FreeBSD 5.2.1-RELEASE of Feb 23, GENERIC kernel > dd dd if=/dev/random of=/dev/twed0s3a bs=1048576 gives dd: /dev/twed0s3a: Operation not permitted when disklabel shows fstype "swap"; when I change the disklabel to fstype "unused", it works. In either case, the partition is *not* being used as swap, as I can verify with swapon. So if this is not a feature, it is a bug. Who would like to know about such an observation - this list, or should this be sent elsewhere? (Feel like this question should be on newbie :) > You might try a bigger size, but that may be as good as it gets. Hmpf, ok. > If you > really want performance, you should use arc4random in a custom userland > program. That's faster, but expect wiping a 40GB disk to take hours > even in that case. Assuming that /dev/zero is as fast as it gets, the limiting step really seems to be the writing - or would you expect /dev/zero to be slow for some odd reasons? When you use dd on your system, to you get similar write rates? > I've got such an application, but I haven't had time > to clean it up and submit it for release. I'll probably do it some day, > but I can't recommend waiting for that. It's only about 800 lines of > code including the man page and a fancy composable operations system to > allow just about any DoD or non-DoD pattern or writes and verifies to be > written on the command line. I'd be happy to beta-test-drive it if you like! :o) > > > 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 that > > > much worse then before (I don't recall an actual number). > > > > That's impressive. Ok, I get the impression that in practice having > > everything that's not dedicated fast'n'dirty work-space gbde encrypted > > might after all be the best solution. > > Probably. Remember, modern CPUs are REALLY fast compared to just about > everything else in the system including main memory. As long as you > stay in cache, you can burn a remarkable number of cycles pretty much > for free. For that matter, if you're operations are stream oriented > (i.e. producing streams of random numbers) only memory bandwidth matters > as long as the working set of the algorithm stays in cache. According to the gbde paper, the encryption can up to double the number of disk-accesses compared to a non-encrypted volume. I hence think you are right that the encryption time per se should be negligible, it will be the extra seek/read/write operations that give the slow-down. Now, if buildworld can do most of its stuff in memory and is CPU rather than I/O bound, that would make little difference. If your application needs to swap and/or is I/O intensive, I guess one should feel it strongly. If I can get my system to have most stuff on gbde partitions with the help of this list, including system ones like /var, I think it's worth a go. I can then have a smaller "fast" partition for temporary not-sensitive work that I could wipe with your utility periodically (or /dev/random at worst). With many thanks 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),' ((!.-'