Date: Tue, 20 Jul 2004 21:03:14 +0100 From: David Kreil <kreil@ebi.ac.uk> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: David Kreil <kreil@ebi.ac.uk> Subject: Re: "sanitizing" disks: wiping swap, non-allocated space, and file-tails Message-ID: <200407202003.i6KK3Et20000@puffin.ebi.ac.uk> In-Reply-To: Your message of "Mon, 19 Jul 2004 09:43:34 PDT." <20040719164334.GA14144@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 a=
nd I =
can proceed.
Would you know how I could hook into the shutdown procedure *after* the =
processes have been terminated?
> > 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.
That sounds like coding it would require more disk interface knowledge th=
an I =
have :-/
> > > The easiest way to scrub a disk is:
> > >
> > > dd if=3D/dev/random of=3D/dev/<disk> bs=3D<sthg big>
> > > <repeat a few times>
I noticed that it will refuse to let me do that on swap, even if it is of=
f. Of =
course, I can edit the disklabel to read "unused", run dd, and restore th=
e =
swap disklabel to "swap" but is there another way?
Also, I've just done some tests, and
dd if=3D/dev/random of=3D/dev/<mydisk> bs=3D1048576
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 =
write.
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).
> > > 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
> bit 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.
Ah, ok! Thanks for the pointers :)
> > > If you swap, your performance will be suck enough that encrypting i=
t
> > > 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 tha=
t
> much worse then before (I don't recall an actual number).
That's impressive. Ok, I get the impression that in practice having every=
thing that's not dedicated fast'n'dirty work-space gbde encrypted might a=
fter all be the best solution.
With many thanks again for your help,
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),' ((!.-'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407202003.i6KK3Et20000>