From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 19:18:34 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCC5516A4CE for ; Wed, 27 Apr 2005 19:18:34 +0000 (GMT) Received: from parse.com (ottawa-hs-206-191-28-202.s-ip.magma.ca [206.191.28.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFCB243D46 for ; Wed, 27 Apr 2005 19:18:33 +0000 (GMT) (envelope-from root@parse.com) Received: (from root@localhost) by parse.com (8.8.8/8.8.8) id PAA05842 for freebsd-fs@freebsd.org; Wed, 27 Apr 2005 15:18:33 -0400 Message-Id: <200504271918.PAA05842@parse.com> To: freebsd-fs@freebsd.org Date: Wed, 27 Apr 2005 15:18:33 -0400 (EDT) From: "Robert Krten" X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Background block scrubbing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 19:18:34 -0000 I don't know where to ask but here :-) Is there a utility that does background unused block scrubbing? What I'm thinking of is something that looks for unused blocks on the disk, and then writes zeros, then random, then more random, etc, to them for security applications. It would need to have some cooperation from the filesystem so that it could lock down a block (or ten, or some number) at a time that it could then go and "scrub" during idle periods... Since it would only allocate a few blocks at a time, it wouldn't need to have a mechanism to release them (IMHO). If there's nothing like it, can anyone give hints on where I should look in the source tree for an appropriate place to put such a thing? Thanks in advance! Cheers, -RK -- Robert Krten, PARSE Software Devices +1 613 599 8316. Looking for Digital Equipment Corp. PDP-1 through PDP-15 minicomputers! From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 21:17:58 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBDC316A4CE for ; Wed, 27 Apr 2005 21:17:58 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47A5A43D1F for ; Wed, 27 Apr 2005 21:17:58 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFM00MQ1IWCZ270@bgo1smout1.broadpark.no> for freebsd-fs@freebsd.org; Wed, 27 Apr 2005 23:12:12 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFM003IMJ7JIB30@bgo1sminn1.broadpark.no> for freebsd-fs@freebsd.org; Wed, 27 Apr 2005 23:18:55 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 515544516B; Wed, 27 Apr 2005 23:17:56 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id AEA9845171; Wed, 27 Apr 2005 23:17:50 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id A0E5933C09; Wed, 27 Apr 2005 23:17:50 +0200 (CEST) Date: Wed, 27 Apr 2005 23:17:50 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <200504271918.PAA05842@parse.com> To: Robert Krten Message-id: <867jin2a2p.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <200504271918.PAA05842@parse.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: freebsd-fs@freebsd.org Subject: Re: Background block scrubbing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 21:17:58 -0000 "Robert Krten" writes: > Is there a utility that does background unused block scrubbing? > > What I'm thinking of is something that looks for unused blocks on the > disk, and then writes zeros, then random, then more random, etc, to them > for security applications. That's not how it's done. Here's a good explanation of how to do it and why it must be done that way: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > It would need to have some cooperation from the filesystem so that it cou= ld > lock down a block (or ten, or some number) at a time that it could then go > and "scrub" during idle periods... Since it would only allocate a few > blocks at a time, it wouldn't need to have a mechanism to release them (I= MHO). To do this safely, you have to first scrub the entire disk before partitioning / newfsing it, and when the disk is in use, scrub every single block that has held data but no longer does as soon as it is deallocated, and before reporting the I/O operation complete to the filesystem. Performance would be abysmal (it takes 35 passes to fully scrub each block), so in real life you'd be better off encrypting the disk (using gbde or something similar), and only scrubbing or bulk erasing it when you decomission it. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 21:25:12 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 989BF16A4CE for ; Wed, 27 Apr 2005 21:25:12 +0000 (GMT) Received: from parse.com (ottawa-hs-206-191-28-202.s-ip.magma.ca [206.191.28.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6C043D2F for ; Wed, 27 Apr 2005 21:25:11 +0000 (GMT) (envelope-from aef-bounce@parse.com) Received: (from rk@localhost) by parse.com (8.8.8/8.8.8) id RAA20372; Wed, 27 Apr 2005 17:25:11 -0400 Date: Wed, 27 Apr 2005 17:25:11 -0400 Message-Id: <200504272125.RAA20372@parse.com> X-Authentication-Warning: gateway.ott.parse.com: rk set sender to aef-bounce using -f From: "Authorized Email System" To: freebsd-fs@freebsd.org X-Generated: aef v0.093 (C) Copyright 2003 1230599 Ontario Inc., all rights reserved X-Sent-To: freebsd-fs@freebsd.org Subject: Your email [ =?windows-1251?b?QUJWLkJHIODi8u7s4PLo9+XtIO7y4+7i7vA=?= ] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 21:25:12 -0000 THIS IS AN AUTOMATICALLY-GENERATED EMAIL MESSAGE, PLEASE READ! Recently, you (or someone using your email address) sent an email to an email address @parse.com [from IP address 194.153.145.92] Due to the existing high volume of spam email that we receive, your email is currently in a holding area, and will not be presented to the recipient until you click on the following URL: http://www.parse.com:8080/cgi-bin/aefweb?whitelist=E8FE903E We will hold the email for 15 days, after which point it will be deleted. By clicking on the above URL, you will cause the queued email to be delivered, as well as all future emails. Please note the legal text below. For more information on this procedure, as well as frequently asked questions (FAQs) please visit the following URL: http://www.parse.com/aef/index.html We thank you for your understanding and cooperation in this matter. ------------------------------------------------------------------------------ LEGAL TEXT: We have a strict, zero-tolerance policy regarding spam email. Any form of advertising, or Unsolicited Commercial Email (UCE), which is sent will be dealt with severely, including but not limited to placing your email address on a blacklist, notifying your ISP, etc. at our sole discretion. By clicking on the provided URL, you thereby certify that the sent email is neither spam nor UCE, and in case it is, you thereby agree to be liable for any and all related costs associated with damages, direct, consequential, or other, however caused. ------------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Wed Apr 27 22:43:31 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7843716A4CE for ; Wed, 27 Apr 2005 22:43:31 +0000 (GMT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E9BF43D73 for ; Wed, 27 Apr 2005 22:43:31 +0000 (GMT) (envelope-from ellard@eecs.harvard.edu) Received: from localhost (localhost.eecs.harvard.edu [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 390A754C9D6; Wed, 27 Apr 2005 18:43:30 -0400 (EDT) Received: from mail.eecs.harvard.edu ([127.0.0.1]) by localhost (bowser.eecs.harvard.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52879-09; Wed, 27 Apr 2005 18:43:30 -0400 (EDT) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id 0FB2254C9D4; Wed, 27 Apr 2005 18:43:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 0C57554C9CA; Wed, 27 Apr 2005 18:43:30 -0400 (EDT) Date: Wed, 27 Apr 2005 18:43:29 -0400 (EDT) From: Daniel Ellard To: freebsd-fs@freebsd.org In-Reply-To: <867jin2a2p.fsf@xps.des.no> Message-ID: <20050427183037.E46204@bowser.eecs.harvard.edu> References: <200504271918.PAA05842@parse.com> <867jin2a2p.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by amavisd-new at eecs.harvard.edu cc: Robert Krten Subject: Re: Background block scrubbing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 22:43:31 -0000 On Wed, 27 Apr 2005, [iso-8859-1] Dag-Erling Sm=F8rgrav wrote: > "Robert Krten" writes: > > Is there a utility that does background unused block scrubbing? > > > > What I'm thinking of is something that looks for unused blocks on the > > disk, and then writes zeros, then random, then more random, etc, to the= m > > for security applications. > > That's not how it's done. Here's a good explanation of how to do it > and why it must be done that way: > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html That's not how it's done *now*, but it could be done like that in the future. The problem with this approach is that it might take an unknown amount of time before a particular block is sufficiently scrubbed. If the user needs to have something scrubbed right away (or by any given time) then this won't work -- but if the user has relaxed time constraints and a good amount of idle time, this doesn't seem like a bad way to get started on the process. Another suggestion -- look at the work done on free block scheduling, which opportunistically schedules I/Os for "free" during time that would ordinarily be rotational delays. There was a study a few years ago that showed that a free block scheduler could read or write every block on a disk in a matter of hours, even if the disk was heavily utilized during this period -- no need to wait for the disk to be idle. [Note that this scheduleing is "free" in terms of time, but not power or wear -- if you've got a disk that's designed to be idle a good fraction of the time, like most PC disks, this could cook it.] -Dan From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 13:04:40 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD2D416A4CE for ; Thu, 28 Apr 2005 13:04:40 +0000 (GMT) Received: from parse.com (ottawa-hs-206-191-28-202.s-ip.magma.ca [206.191.28.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCC2443D55 for ; Thu, 28 Apr 2005 13:04:39 +0000 (GMT) (envelope-from root@parse.com) Received: (from root@localhost) by parse.com (8.8.8/8.8.8) id JAA02215; Thu, 28 Apr 2005 09:04:35 -0400 Message-Id: <200504281304.JAA02215@parse.com> To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 28 Apr 2005 09:04:35 -0400 (EDT) From: "Robert Krten" In-Reply-To: <867jin2a2p.fsf@xps.des.no> from "=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=" at Apr 27, 2005 11:17:50 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org Subject: Re: Background block scrubbing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 13:04:40 -0000 =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= sez... > > "Robert Krten" writes: > > Is there a utility that does background unused block scrubbing? > > > > What I'm thinking of is something that looks for unused blocks on the > > disk, and then writes zeros, then random, then more random, etc, to them > > for security applications. > > That's not how it's done. Here's a good explanation of how to do it > and why it must be done that way: > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Thanks! > > It would need to have some cooperation from the filesystem so that it could > > lock down a block (or ten, or some number) at a time that it could then go > > and "scrub" during idle periods... Since it would only allocate a few > > blocks at a time, it wouldn't need to have a mechanism to release them (IMHO). > > To do this safely, you have to first scrub the entire disk before > partitioning / newfsing it, and when the disk is in use, scrub every > single block that has held data but no longer does as soon as it is > deallocated, and before reporting the I/O operation complete to the > filesystem. Performance would be abysmal (it takes 35 passes to fully > scrub each block), so in real life you'd be better off encrypting the > disk (using gbde or something similar), and only scrubbing or bulk > erasing it when you decomission it. Gotcha. I wasn't aware it was *35* :-) I was thinking/hoping more like 3 or 4 with random garbage. Thanks for the info! Cheers, -RK -- Robert Krten, PARSE Software Devices +1 613 599 8316. Realtime Systems Architecture, Consulting, Books and Training at www.parse.com Looking for Digital Equipment Corp. PDP-1 through PDP-15 minicomputers! From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 14:02:50 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9D5916A4CE for ; Thu, 28 Apr 2005 14:02:50 +0000 (GMT) Received: from web41203.mail.yahoo.com (web41203.mail.yahoo.com [66.218.93.36]) by mx1.FreeBSD.org (Postfix) with SMTP id 47F8243D54 for ; Thu, 28 Apr 2005 14:02:50 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 88066 invoked by uid 60001); 28 Apr 2005 14:02:49 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=QC6Mm+1BOEKAfOQs8UJMbFUTULGLGTF7Cw074URf6mjoV5rTgqxUnamUBWGyN7t1hw5Ds/ci+HacT+LtJT4es27qzktCT5ytTNA/MSqzX/70YaCZhGIylWAd1STZLkJ4I/jNJwJXkUP8Yq8DqyJrD0blJPZTR3WDrxHW9ZSE9Hk= ; Message-ID: <20050428140249.88064.qmail@web41203.mail.yahoo.com> Received: from [83.129.189.236] by web41203.mail.yahoo.com via HTTP; Thu, 28 Apr 2005 07:02:49 PDT Date: Thu, 28 Apr 2005 07:02:49 -0700 (PDT) From: Arne "Wörner" To: Robert Krten In-Reply-To: <200504281304.JAA02215@parse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-fs@freebsd.org Subject: Re: Background block scrubbing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 14:02:50 -0000 --- Robert Krten wrote: > =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= sez... > > "Robert Krten" writes: > > > Is there a utility that does background unused block > > > scrubbing? > > > > > > What I'm thinking of is something that looks for unused > > > blocks on the > > > disk, and then writes zeros, then random, then more > > > random, etc, to them for security applications. > > > > That's not how it's done. Here's a good explanation of how > > to do it and why it must be done that way: > > > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > I think, that article dramatizes the problem a little, because: It says itself in the end, that with modern hard discs writing random data would be enough (so it is just 8 or so; I did not read the whole article and I am not so good in such things, but I do not know, why it should be possible to know, if a suspected former value of a bit should be the value the attacker is looking for (e. g. MY_DATA, RANDOM_1, RANDOM_2: since just RANDOM_2 is known in the beginning I do not see how an attacker should find MY_DATA by looking at slight variations in magnetization without knowing RANDOM_1); of course it would be necessary to chose good random data (no repetitive/periodic behaviour)). Maybe I should read that article closer... :-) > Gotcha. I wasn't aware it was *35* :-) I was thinking/hoping > more like 3 or 4 with random garbage. > (citation from the above mentioned paper:) "Modern PRML/EPRML" drives (whatever that might be; I think my hard discs both do PRML) just need some random data passes... So you should first check, which kind of drive you need a tool for. Furthermore overwriting the old data once with zeroes should protect you against most attackers... Especially when they are remote attackers, that have to use your operating system for the attack... Maybe you should analysze the kind of attacks, you want to care for: Will they get physical access to your hard disc? Or will they just read from the raw device (/dev/ad0...) with "dd" or so? -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 17:28:38 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF34C16A4CE for ; Thu, 28 Apr 2005 17:28:38 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F4443D3F for ; Thu, 28 Apr 2005 17:28:38 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3SHSb5j017348; Thu, 28 Apr 2005 10:28:37 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3SHSaqn017347; Thu, 28 Apr 2005 10:28:36 -0700 Date: Thu, 28 Apr 2005 10:28:36 -0700 From: Brooks Davis To: Arne =?iso-8859-1?Q?W=F6rner?= Message-ID: <20050428172836.GA30626@odin.ac.hmc.edu> References: <200504281304.JAA02215@parse.com> <20050428140249.88064.qmail@web41203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20050428140249.88064.qmail@web41203.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-fs@freebsd.org cc: Robert Krten Subject: Re: Background block scrubbing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 17:28:38 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 28, 2005 at 07:02:49AM -0700, Arne W=F6rner wrote: > --- Robert Krten wrote: > > Gotcha. I wasn't aware it was *35* :-) I was thinking/hoping > > more like 3 or 4 with random garbage. > >=20 > (citation from the above mentioned paper:) "Modern PRML/EPRML" > drives (whatever that might be; I think my hard discs both do > PRML) just need some random data passes... So you should first > check, which kind of drive you need a tool for. The paper is actually pretty clean that you do not need all 35 passes. Most of the patterns are for specific encodins your drive doesn't use. IIRC (it's been a few years since I read this and the really stupid DoD standard it refrences), for any drive other than a floppy random is the only thing that matters and for a floppy breaking the case, removing the floppy, and burning it is much faster and 100% effective. With HDDs there's the additional issue that bad block remapping happens below the surface so you can't actually know you've written to the only physical copy of the block. The issue the paper doesn't address that is relevent today is modern flash drives. There is clearly going to be resedue of the bits in the flash is it's there in DRAM, but you can't even get direct access to the raw bits due to wear balancing. What I'd like to see is a simple zeroing of blocks when they are freed so deletes actually remove the files from the hot disk. That would be a slight (though imperfect) improvement over the current situation for hot disks. You can then use gbde for cold disk protection. -- Brooks --=20 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 --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCcR1DXY6L6fI4GtQRAgrPAKCqdu0Y7Ye35XinMK/gkkjMspKomwCeNqNk ZPq0aVSPueR8Enuf8gT0TYg= =mxOf -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 28 22:29:22 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D623C16A4CE for ; Thu, 28 Apr 2005 22:29:22 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7735F43D41 for ; Thu, 28 Apr 2005 22:29:22 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j3SMQMRX018701; Thu, 28 Apr 2005 18:26:22 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j3SMQLRK018700; Thu, 28 Apr 2005 18:26:21 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 28 Apr 2005 18:26:21 -0400 From: David Schultz To: Arne WXrner Message-ID: <20050428222621.GA18634@VARK.MIT.EDU> Mail-Followup-To: Arne WXrner , Robert Krten , freebsd-fs@freebsd.org References: <200504281304.JAA02215@parse.com> <20050428140249.88064.qmail@web41203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428140249.88064.qmail@web41203.mail.yahoo.com> cc: freebsd-fs@FreeBSD.ORG cc: Robert Krten Subject: Re: Background block scrubbing X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 22:29:22 -0000 On Thu, Apr 28, 2005, Arne WXrner wrote: > --- Robert Krten wrote: > > =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= sez... > > > "Robert Krten" writes: > > > > Is there a utility that does background unused block > > > > scrubbing? > > > > > > > > What I'm thinking of is something that looks for unused > > > > blocks on the > > > > disk, and then writes zeros, then random, then more > > > > random, etc, to them for security applications. > > > > > > That's not how it's done. Here's a good explanation of how > > > to do it and why it must be done that way: > > > > > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > > I think, that article dramatizes the problem a little, because: It > says itself in the end, that with modern hard discs writing random > data would be enough (so it is just 8 or so; I did not read the > whole article and I am not so good in such things, but I do not If you're truly paranoid, 1000 rewrites isn't enough. Consider, for instance, that when the disk encounters problems reading a particular sector, it will automatically reallocate that (logical) sector somewhere else. Hence, the original sensitive information remains on the disk no matter how many times the OS tells the disk to write over the sector. Furthermore, the firmware programs on modern high-end disk arrays are just like operating systems in the sense they have their own bugs, race conditions, etc. Misdirected and phantom writes, however rare, can also expose your secret data. If you're going to write your data to disk unencrypted, you have to trust that everything from the OS I/O path to the device driver to the disk controller to the disk is working correctly. By simply using encryption, you can save on all of those rewrites with random garbage and at the same time take a lot out of the trusted computing base.