"sanitizing" disks: wiping swap, non-allocated space, and
brooks at one-eyed-alien.net
Tue Jul 20 15:00:36 PDT 2004
On Tue, Jul 20, 2004 at 09:03:14PM +0100, David Kreil wrote:
> 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 and I
> can proceed.
> 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.
> > > > 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?
> Also, I've just done some tests, and
> dd if=/dev/random of=/dev/<mydisk> bs=1048576
> 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
> 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).
You might try a bigger size, but that may be as good as it gets. 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. 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.
> > > > 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).
> 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.
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
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20040720/4345f14d/attachment.bin
More information about the freebsd-fs