Date: Sun, 23 Nov 2003 09:50:32 -0800 From: Wes Peters <wes@softweyr.com> To: Stefan =?iso-8859-1?q?E=DFer?= <se@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? Message-ID: <200311230950.32243.wes@softweyr.com> In-Reply-To: <20031123121501.GA1133@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230016.31498.wes@softweyr.com> <20031123121501.GA1133@StefanEsser.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 23 November 2003 04:15 am, Stefan E=DFer wrote:
> On 2003-11-23 00:16 -0800, Wes Peters <wes@softweyr.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311230950.32243.wes>