From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 04:15:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76B0016A4CF; Sun, 23 Nov 2003 04:15:12 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8553243F75; Sun, 23 Nov 2003 04:15:10 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng8.kundenserver.de with esmtp (Exim 3.35 #1) id 1ANt8q-0005jk-00; Sun, 23 Nov 2003 13:15:04 +0100 Received: from [80.132.236.72] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ANt8q-0005S0-00; Sun, 23 Nov 2003 13:15:04 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 75D675F18; Sun, 23 Nov 2003 13:15:02 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 21AD41F18; Sun, 23 Nov 2003 13:15:02 +0100 (CET) Date: Sun, 23 Nov 2003 13:15:01 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Wes Peters Message-ID: <20031123121501.GA1133@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311211333.39520.wes@softweyr.com> <20031121235607.GB16700@StefanEsser.FreeBSD.org> <200311230016.31498.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200311230016.31498.wes@softweyr.com> User-Agent: Mutt/1.5.5.1i Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2003 12:15:12 -0000 On 2003-11-23 00:16 -0800, Wes Peters wrote: > On Friday 21 November 2003 03:56 pm, Stefan E=DFer wrote: > > A simple algorithm could just mark each buffer with a special > > kind of dirty flag and a counter for the pass number (in fact, > > the existing dirty flag could be used, and a counter set to the > > number of passes required, with 0 indicating that the buffer is > > to be flushed to disk "as is" in the normal way). >=20 > Oh, but you're wrong, if you actually want to ERASE the data on the dis= k=20 > platters. That's why I've referred people to the obliterate program in= =20 > ports several times. Read the references contained there, then come ba= ck=20 > to this discussion. This is rude! It's been some time since I read the Gutmann paper, but I still remember=20 the points he made and even quite a number of the details. Either my (English) language skills are insufficient to make my point,=20 or you just didn't read what I wrote. I thought it was obvious that=20 if I'm talking of several passes, that each one writes specific data=20 (either a complement of the original data, a suitable pattern or random=20 data).=20 What I'm suggesting is to have the obliteration implemented as an add on to the dirty buffer flush, with the difference that the=20 buffer contents is prepared for the next step of the erasure process, written out, and then not declared free but again prepared for the next overwrite pass. A counter is required to keep the required state information for each individual buffer. AFAIK, there is no=20 need to retain original data (or its complement) for the process, so in fact all that is needed is a pass counter and the very simple FA. There is no need for a special thread, and that was the point I was trying to make. Takling of obliterate: There is the patterns[] array and the "passno" variable attached to a buffer could select one of those patterns on each pass of the elevator. (Well, may be a seperate thread might be better to prepare buffers by filling in the correct patterns at slightly=20 reduced priority ...) > If you just want to zero the blocks, that is a lot easier, but you're n= ot=20 > really protecting anything from anyone who can get their hands on the=20 > disk. Who is talking about just zeroing blocks ? Please take the time to actually read the messages you reply to ... Regards, STefan