[PATCH] erofs: move erofs out of staging
Chao Yu
yuchao0 at huawei.com
Wed Aug 21 11:34:02 AEST 2019
On 2019/8/20 23:56, Theodore Y. Ts'o wrote:
> The reason why there needs to be at least some file system specific
> code for fuzz testing is because for efficiency's sake, you don't want
> to fuzz every single bit in the file system, but just the ones which
> are most interesting (e.g., the metadata blocks). For file systems
> which use checksum to protect against accidental corruption, the file
> system fuzzer needs to also fix up the checksums (since you can be
> sure malicious attackers will do this).
Yup, IMO, if we really want such tool, it needs to:
- move all generic fuzz codes (trigger random fuzzing in meta/data area) into
that tool, and
- make filesystem generic fs_meta/file_node lookup/inject/pack function as a
callback, such as
* .find_fs_sb
* .inject_fs_sb
* .pack_fs_sb
* .find_fs_bitmap
* .inject_fs_bitmap
* .find_fs_inode_bitmap
* .inject_fs_inode_bitmap
* .find_inode_by_num
* .inject_inode
* .pack_inode
* .find_tree_node_by_level
...
then specific filesystem can fill the callback to tell how the tool can locate a
field in inode or a metadata in tree node and then trigger the designed fuzz.
It will be easier to rewrite whole generic fwk for each filesystem, because
existed filesystem userspace tool should has included above callback's detail
codes...
> On Tue, Aug 20, 2019 at 10:24:11AM +0800, Chao Yu wrote:
>> filesystem fill the tool's callback to seek a node/block and supported fields
>> can be fuzzed in inode.
>
> What you *can* do is to make the file system specific portion of the
> work as small as possible. Great work in this area is Professor Kim's
> Janus[1][2] and Hydra[2] work. (Hydra is about to be published at SOSP 19,
> and was partially funded from a Google Faculty Research Work.)
>
> [1] https://taesoo.kim/pubs/2019/xu:janus.pdf
> [2] https://github.com/sslab-gatech/janus
> [3] https://github.com/sslab-gatech/hydra
Thanks for the information!
It looks like janus and hydra alreay have generic compress/decompress function
across different filesystems, it's really a good job, I do think it may be the
one once it becomes more generic.
Thanks
>
More information about the Linux-erofs
mailing list