"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
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),' ((!.-'
More information about the freebsd-fs
mailing list