Date: Tue, 20 Jul 2004 21:03:14 +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: <200407202003.i6KK3Et20000@puffin.ebi.ac.uk> In-Reply-To: Your message of "Mon, 19 Jul 2004 09:43:34 PDT." <20040719164334.GA14144@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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/<disk> bs=3D<sthg big> > > > <repeat a few times> 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/<mydisk> 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),' ((!.-'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407202003.i6KK3Et20000>