"sanitizing" disks: wiping swap, non-allocated space, and
kreil at ebi.ac.uk
Fri Jul 16 18:54:35 PDT 2004
Many thanks for your fast and helpful reply!
> [Please don't cross post so much.]
I'm sorry. I had sent it to "ports" two weeks ago, assuming that external
programs might be required and then didn't quite know where to turn next. I
guess I should have tried individual groups at a time.
> The only way to clean a file system I can think of is, to dump the fs,
> scrub the disk, restore the fs. That will keep only real data and
> remove all the junk.
Ok, I can do that once to start from a clean slate but it would not be
practical to do this regularly.
> You should be able to scrub swap at shutdown if
> you use swapoff to disable it, but you've got to be sure it's all unused
> first. You can't trust this though because you don't know the system
> will shut down cleanly.
> There is a currently null operation in the disk code that acts when
> a block is no longer used. It should be possible to hook into that
> code to implement some sort of scrubber. It wouldn't be reliable for
> the same reason that a swap scrubber can't be, but it would be OK most
> of the time.
Yes, both approaches would already improve my situation considerably.
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)?
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?
> The easiest way to scrub a disk is:
> dd if=3D/dev/random of=3D/dev/<disk> bs=3D<something big>
> <repeat a few times>
> dd if=3D/dev/zero of=3D/dev/<disk> bs=3D<something big>
> This doesn't meet DoD requirements, but only for obsolete reasons.
Interesting - can you say what type of reasons these are? :-)
> > (2) Related to this:
> > I'm also interested in people's personal experiences in using partition
> > or file system encryption options.
> > For performance reasons I'd rather avoid having /tmp and swap and certain=
> > work space on an encrypted disk, hence the need for (1).
> 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
Ah well, since Allan Fields and you seem to agree on this I suppose I should
try to dump/restore my system to a gbde partition.
With many thanks again for your help
and best regards,
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),' ((!.-'
More information about the freebsd-fs