Re: "secure" file flag?

• Previous message: Poul-Henning Kamp: "Re: "secure" file flag?"
• In reply to: Stefan Eßer: "Re: "secure" file flag?"
• Next in thread: Terry Lambert: "Re: "secure" file flag?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: Stefan Eßer <se@FreeBSD.org>
Date: Sun, 23 Nov 2003 09:50:32 -0800

On Sunday 23 November 2003 04:15 am, Stefan Eßer wrote:
> On 2003-11-23 00:16 -0800, Wes Peters <wes@softweyr.com> wrote:
> > On Friday 21 November 2003 03:56 pm, Stefan Eßer 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
necessary to flush the data through the drive cache. It is, because the
patterns have to be applied in order and may not work if applied out of
order. Therefore, you have to flush the data from the drives own cache
onto the platters after you have applied each pattern.

You can optimize this by moving the solution to a different layer or
implementing a kernel thread, but the drive cache sync does need to be
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
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
to the conclusion disk encryption is probably a lower-cost solution. The
big problem with disk encryption is the question "where do I get the keys
from."

-- 
        Where am I, and what am I doing in this handbasket?
Wes Peters                                               wes@softweyr.com
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

• Previous message: Poul-Henning Kamp: "Re: "secure" file flag?"
• In reply to: Stefan Eßer: "Re: "secure" file flag?"
• Next in thread: Terry Lambert: "Re: "secure" file flag?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]