On Thu, Feb 10, 2000 at 03:04:53AM +0100, Jeremy Fitzhardinge wrote:
>
> On 09-Feb-00 Andi Kleen wrote:
> > On Wed, Feb 09, 2000 at 05:35:00PM +0100, Matthew Wilcox wrote:
> >
> > [...]
> >
> > How about secure deletion?
> >
> > 1.3 used to have some simple minded overwriting of deleted data when the
> > 's' attribute was set. That got lost with 2.0+.
> >
> > Secure disk overwriting that is immune to
> > manual surface probing seems to take a lot more effort (Colin Plumb's
> > sterilize does 25 overwrites with varying bit patterns). Such a complicated
> > procedure is probably better kept in user space. What I would like is some
> > way to have a sterilize daemon running, and when a get 's' file gets
> > deleted the VFS would open a new file descriptor for it, pass it to
> > sterilized (sterild?) using a unix control message and let it do its job.
> >
> > What does the audience think? Should such a facility have kernel support
> > or not? I think secure deletion is an interesting topic and it would be
> > nice if Linux supported it better.
>
> You have to be careful that you don't leak the file you're trying to eradicate
> into the swap via the serilize daemon. I guess simply never reading the file
> is a good start.
sterilize does that. You have of course be careful that you didn't leak
its content to swap before (one way around that is encrypted swapping)
>
> The other question is whether you're talking about an ext2-specific thing, or
> whether its a general service all filesystems provide. Many filesystem
I was actually only thinking about ext2 (because only it has a 's' bit
and the thread is about ext2's future)
> designs, including ext3 w/ journalling, reiserfs(?) and the NetApp Wafl
> filesystem, don't let a process overwrite an existing block on disk. Well,
> ext3 does, but only via the journal; wafl never does. There's also the
> question of what happens when you have a RAID device under the filesystem,
> especially with hot-swappable disks.
reiserfs lets you when you don't change the file size (if you do it is possible
that the file is migrated from a formatted node to a unformatted node).
sterilize does not change file sizes.
ext3 only doesn't let you when you do data journaling (good point I forgot
that)
RAID0/RAID1 are no problem I think, because you have always well defined
block(s) to write too. The wipe data does not depend on the old data on
the disk, so e.g. on a simple mirrored configuration both blocks would
be sterilized in parallel.
RAID5 devices could be a problem, especially when they do data journaling
(I think most only journal some metadata). It is not clear how the sterilize
algorithms interact with the XORed blocks.
If you swap your disks inbetween you lost.
>
> Perhaps a better approach, since we're talking about a privileged process, is
> to get a list of raw blocks and go directly to the disk. You'd have to be very
> careful to synchronize with the filesystem...
Not too much. The file still exists, but there are no references to it
outside sterild. No other process can access it. Assuming the file system
does not have fragments and the raw io has block granuality and the file was
fdatasync'ed before you could directly access it without worrying about
any file system interference. If the fs has fragments you need the
infrastructure needed for O_DIRECT (I think that is planned anyways).
With a "invalidate all dirty buffers for file X" call you could optimize
part of the fdatasync writes away, but a good sterilize needs so many
writes anyways (25+) that it probably does not make much difference.
The data would be only really deleted when the system is turned off,
because it could partly still exist in some not yet reused buffers.
-Andi
