"secure" file flag?

[Wes Peters]

On Sunday 23 November 2003 04:15 am, Stefan Eßer wrote:
> On 2003-11-23 00:16 -0800, Wes Peters <wes at 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 at softweyr.com