Re: History file clobbered by multiple simultaneous exits

[Geoff Kuenning]

>       Instead of "junk", secure file systems mark it as needing to be
> zeroed.  Perhaps instead of zeroing it ext3 simply marks it of zero
> length?  Imagine, embedded in the junk are credit cards and passwords
> and you'll begin to understand why zero pages are kept "in-stock" (in
> memory) in the kernel so they can rapidly issue a fresh page.

Perhaps I should mention that file systems are my field.

While you're right that secure-deletion file systems clobber deleted
data, that's the exception rather than the rule.  So your guess about
ext3 is also correct: when you truncate a file, ext3 marks it as zero
length but never overwrites the data.  This is easy to prove on any
machine that has a way of monitoring disk activity (either an LED or via
programs like gkrellm or iotop).  Simply create a multi-gigabyte file,
sync the disk, and cp /dev/null to the file.  The disk will be only
briefly active while the free list is updated, not nearly long enough to
rewrite zeros to the freed blocks.

The difference from zero pages in memory is that the API for memory is
designed around the "give me a block and I'll do things with it later"
model.  So asking for a page doesn't inherently clobber it, and the
kernel has to do that for you.  By contrast, the only way to allocate a
page in a file system is to either write to it or to lseek over it.  The
first case automatically clobbers it; in the second it gets marked as
"demand zero if anybody ever reads it" but the disk never gets
written--in fact, no block is allocated unless you write to it.

(As a historical note, Unix at least through V7 didn't demand-zero newly
allocated memory.  Eventually somebody noticed the bug and a wrote
program to steal passwords that way, prompting a change in the kernel
code.  I also believe that in V6 if you wrote a partial block at the end
of a file, you could get leftover data from another file in the
remainder of the block; since you couldn't read it back--it was past
EOF--it was considered OK to have garbage there, and zeroing the memory
before the write was thought to be too expensive.  Unfortunately my
treasured photocopy of the Lions book is in storage while my office is
being moved, so I can't check the V6 code to be sure.)

> It's an edge case usually only seen during some system crash as you mentioned,
> so I can't see how it would cause the symptom you are seeing, but it's only
> seen in crashes in more mature file systems.  Can you reproduce it on another
> file system like xfs?

Good question.  Unfortunately that's not a practical experiment for me
to run.  :-(
-- 
    Geoff Kuenning   geoff@cs.hmc.edu   http://www.cs.hmc.edu/~geoff/

Paymasters come in only two sizes: one sort shows you where the book
says that you can't have what you've got coming to you; the second
sort digs through the book until he finds a paragraph that lets you
have what you need even if you don't rate it.  Doughty was the second
sort.
        -- Robert A. Heinlein, "The Door Into Summer"