"sanitizing" disks: wiping swap, non-allocated space, and file-tails

Brooks Davis brooks at one-eyed-alien.net
Mon Jul 19 09:43:38 PDT 2004

On Sat, Jul 17, 2004 at 02:54:29AM +0100, David Kreil wrote:
> Dear Brooks,
> 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.

In general, just 1-2 lists is best.  Idealy, you can send to a list a
wait a few days before trying somewhere else.

> > 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.

Other then encrypting the disk, there isn't much else you can do at this
point without kernel modification.

> > 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)?

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.

> 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.

> > 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? :-)

The short form is that the DoD requirements require writing a pattern, a
fit 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.  For the long form, read the standard:


and a nice modern analysis:


> > > (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 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 that
much worse then before (I don't recall an actual number).

-- Brooks

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20040719/d6462421/attachment.bin

More information about the freebsd-fs mailing list