From owner-freebsd-fs@FreeBSD.ORG Tue Jul 20 22:00:36 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 9A4AC16A4CE for ; Tue, 20 Jul 2004 22:00:36 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6153C43D46 for ; Tue, 20 Jul 2004 22:00:36 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i6KM0XOF027350; Tue, 20 Jul 2004 15:00:33 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i6KM0Xnp027349; Tue, 20 Jul 2004 15:00:33 -0700 Date: Tue, 20 Jul 2004 15:00:33 -0700 From: Brooks Davis To: David Kreil Message-ID: <20040720220033.GA12560@Odin.AC.HMC.Edu> References: <20040719164334.GA14144@Odin.AC.HMC.Edu> <200407202003.i6KK3Et20000@puffin.ebi.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <200407202003.i6KK3Et20000@puffin.ebi.ac.uk> User-Agent: Mutt/1.5.4i cc: freebsd-fs@freebsd.org 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:00:36 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 20, 2004 at 09:03:14PM +0100, David Kreil wrote: >=20 > Dear Brooks, >=20 > Thank you very much again for your comments. >=20 > > > 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)? > >=20 > > 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. >=20 > Ok, so if I do it after the processes' shutdown, any remaining stuff in= =20 > virtual memory should easily fit into physical memory. swapoff would then= move=20 > any swapped out pages back to physical memory before disconnecting swap a= nd I=20 > can proceed. >=20 > Would you know how I could hook into the shutdown procedure *after* the= =20 > processes have been terminated? Unfortunaly, I don't. I suspect you may have to hack init. > > > > The easiest way to scrub a disk is: > > > > > > > > dd if=3D/dev/random of=3D/dev/ bs=3D > > > > >=20 > I noticed that it will refuse to let me do that on swap, even if it is of= f. Of=20 > course, I can edit the disklabel to read "unused", run dd, and restore th= e=20 > swap disklabel to "swap" but is there another way? That's broken. Which OS are you using? > Also, I've just done some tests, and >=20 > dd if=3D/dev/random of=3D/dev/ bs=3D1048576 >=20 > only writes at 6.5MB/s on my system (/dev/zero gives 7.9MB/s). Is that=20 > typical? My drives theoretically should do 30-40MB/s on read, and 20-30MB= /s on=20 > write. >=20 > If these results are "normal", however, that means, for a 10GB swap file = and,=20 > say 6 wipes, I'd be waiting 3h on shutdown, while a BND-safe thorough 20 = wipes=20 > would take half a day. Not really practical :-/ > So unless you tell me that I should be able to achieve much faster write= =20 > speeds, I think I'll have to ditch the idea of regularly wiping swap (or= =20 > anything else for that matter). You might try a bigger size, but that may be as good as it gets. 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. 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. > > > > 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. > >=20 > > 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). >=20 > 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. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA/ZYAXY6L6fI4GtQRAg65AKDiI5VWP/3gRvHtISrLBNpS6bylogCg5zR2 KD4SFBK1c72bOW4o7kkTgfU= =AMgA -----END PGP SIGNATURE----- --huq684BweRXVnRxX--