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

David Kreil kreil at ebi.ac.uk
Tue Jul 20 15:24:53 PDT 2004

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


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,


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 mailing list