Date: Tue, 20 Jul 2004 23:24:50 +0100 From: David Kreil <kreil@ebi.ac.uk> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: David Kreil <kreil@ebi.ac.uk> Subject: Re: "sanitizing" disks: wiping swap, non-allocated space, and file-tails Message-ID: <200407202224.i6KMOoN05374@puffin.ebi.ac.uk> In-Reply-To: Your message of "Tue, 20 Jul 2004 15:00:33 PDT." <20040720220033.GA12560@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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/<disk> bs=<sthg big> > > > > > <repeat a few times> > > > > 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),' ((!.-'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407202224.i6KMOoN05374>