tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[GSoC 2013] Implement file system flags to scrub data blocks before deletion

Thank you for any previous suggestions.
I would like to ask for more, though, as I attach the following:

Midterm Report

In short, the state of my project is as follows:
a) user is able to mark a file with a flag under both ffs and ext2fs
b) when a file marked that way is truncated, data blocks are zeroed in a buffer
   and saved back on the backing store

The flag can be set for a file with chflags
(eg. "chflags scrub ~/.ssh/id_rsa").
It is an owner-type flag (in contrast to a super-user only).
In order to achieve it I have modified:
* in user land:
- /lib/libutil/stat_flags.c,
* in kernel land:
- /sys/sys/stat.h,
- /sys/ufs/ext2fs/ext2fs_vnops.c.

In ext2fs the flag is saved in the file system under ext2 flags and represented
as "secure deletion", though it is settable with chflags and visible with
"ls -lo".

To implement b) the following files have been changed:
- /sys/ufs/ext2fs/ext2fs_inode.c,
- /sys/ufs/ffs/ffs_inode.c,
that is procedures for truncating an inode.
Common code is abstracted under /sys/ufs/ within ufs_scrub.h and ufs_scrub.c.

The current behavior is that the operation blocks until data blocks are
saved back to the backing store and the rest of truncating operation is done.
As this can take a long time, I thought of implementing it in a form of a work
queue, which would collect block numbers and perform scrubbing one cylinder
group (or block) at a time. However, that scrub-behind-like behavior complicated
matters greatly and I haven't come up with any usable solution in that fashion

When SCRUB_DEBUG option is defined on compilation the mechanism produces some
diagnostic messages. With help of the vnd(4), fsdb(8), debugfs(8), dd(1), od(1)
and raw device handles I was able to do some testing. After using vnd for
a while I though it unnecessary, as for now I am testing on a virtual machine
and I can add disks on the virtual machine level. In general, the mechanism
appeared to work with deleting a whole file, as well as truncating it to
a smaller size. I suspect it to be flawed with a race condition though, in which
a thread could see a lot of rubbish near the end of file just before truncation,
it needs a little more testing.

At first, I planned to introduce a file system mount flag for scrubbing all
files when mounted with such, but resigned from the idea as it seems unneeded,
therefore code for mounting stayed unchanged.

The mechanism does not deal with blocks claimed by snapshots but it looks like
it would be desired to include that functionality too, I could try to do so
after finishing what I have planned:
1) flash bugs out of current solution, ensure robustness
2) add multi-pass overwrite with a simple prng
3) update documentation

I have created a repository hosting code of this project here [1].


Przemyslaw Sierocinski

Home | Main Index | Thread Index | Old Index