From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 09:50:35 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 EF39216A4CE; Sun, 23 Nov 2003 09:50:34 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB54B43F93; Sun, 23 Nov 2003 09:50:33 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 22EC35B650; Sun, 23 Nov 2003 09:49:13 -0800 (PST) From: Wes Peters Organization: Softweyr To: Stefan =?iso-8859-1?q?E=DFer?= Date: Sun, 23 Nov 2003 09:50:32 -0800 User-Agent: KMail/1.5.4 References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230016.31498.wes@softweyr.com> <20031123121501.GA1133@StefanEsser.FreeBSD.org> In-Reply-To: <20031123121501.GA1133@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200311230950.32243.wes@softweyr.com> 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 17:50:35 -0000 On Sunday 23 November 2003 04:15 am, Stefan E=DFer wrote: > 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). > > > > Oh, but you're wrong, if you actually want to ERASE the data on the > > disk platters. That's why I've referred people to the obliterate > > program in ports several times. Read the references contained there, > > then come back to this discussion. > > This is rude! > > It's been some time since I read the Gutmann paper, but I still > remember the points he made and even quite a number of the details. > > Either my (English) language skills are insufficient to make my point, > or you just didn't read what I wrote. I thought it was obvious that > if I'm talking of several passes, that each one writes specific data > (either a complement of the original data, a suitable pattern or random > data). I'm sorry, I must've cut out the part where you wrote that it isn't=20 necessary to flush the data through the drive cache. It is, because the=20 patterns have to be applied in order and may not work if applied out of=20 order. Therefore, you have to flush the data from the drives own cache=20 onto the platters after you have applied each pattern. You can optimize this by moving the solution to a different layer or=20 implementing a kernel thread, but the drive cache sync does need to be=20 done. > What I'm suggesting is to have the obliteration implemented as an > add on to the dirty buffer flush, with the difference that the > 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 > 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. Yes, I see. For each block, you store the index of the next pattern to be= =20 written as each current pattern > 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 reduced priority ...) This would probably be an optimal solution. Given the difference between CPU performance and disk I/O speed, I've come= =20 to the conclusion disk encryption is probably a lower-cost solution. The=20 big problem with disk encryption is the question "where do I get the keys=20 from." =2D-=20 Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com