From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Chao Yu <yuchao0@huawei.com>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@infradead.org>,
Amir Goldstein <amir73il@gmail.com>,
Dave Chinner <david@fromorbit.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Miao Xie <miaoxie@huawei.com>, devel <devel@driverdev.osuosl.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Richard Weinberger <richard@nod.at>,
Qu Wenruo <quwenruo.btrfs@gmx.com>,
Eric Biggers <ebiggers@kernel.org>,
torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Jaegeuk Kim <jaegeuk@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>, Pavel Machek <pavel@denx.de>,
David Sterba <dsterba@suse.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-erofs <linux-erofs@lists.ozlabs.org>
Subject: Re: [PATCH] erofs: move erofs out of staging
Date: Tue, 20 Aug 2019 18:48:18 -0700 [thread overview]
Message-ID: <20190821014818.GB1037422@magnolia> (raw)
In-Reply-To: <9d8f88ee-4b81-bdfa-b0d7-9c7d5d54e70a@huawei.com>
On Wed, Aug 21, 2019 at 09:34:02AM +0800, Chao Yu wrote:
> 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
What about group descriptors? AG headers? The AGFLWTFBBQLOL?
> * .find_fs_bitmap
> * .inject_fs_bitmap
Probably want an find/inject for log blocks too.
Oh, wait, XFS doesn't log blocks like jbd2 does. :) :)
> * .find_fs_inode_bitmap
> * .inject_fs_inode_bitmap
XFS has an inode bitmap? ;)
(This is why there's no generic fuzz tool; every fs is different enough
that doing so would be sort of a mess.)
((Granted, you could also look at how xfstests uses the xfs_db fuzz
command so at least it would be systematic...))
> * .find_inode_by_num
> * .inject_inode
> * .pack_inode
> * .find_tree_node_by_level
> ...
What about the name/value btrees? (Ok, I'll stop now.)
--D
> 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
>
> >
next prev parent reply other threads:[~2019-08-21 1:51 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-17 8:23 [PATCH] erofs: move erofs out of staging Gao Xiang
2019-08-17 21:19 ` Richard Weinberger
2019-08-17 22:07 ` Gao Xiang
2019-08-17 23:25 ` Richard Weinberger
2019-08-17 23:38 ` Gao Xiang
2019-08-18 0:04 ` Gao Xiang
2019-08-18 0:52 ` Gao Xiang
2019-08-18 8:16 ` Richard Weinberger
2019-08-18 8:45 ` Gao Xiang
2019-08-18 9:03 ` Richard Weinberger
2019-08-18 9:09 ` Greg Kroah-Hartman
2019-08-18 9:21 ` Richard Weinberger
2019-08-18 10:12 ` Chao Yu
2019-08-18 15:11 ` Theodore Y. Ts'o
2019-08-18 15:58 ` Christoph Hellwig
2019-08-18 16:16 ` Eric Biggers
2019-08-18 16:22 ` Christoph Hellwig
2019-08-18 16:33 ` Gao Xiang
2019-08-18 17:29 ` Eric Biggers
2019-08-18 17:47 ` Christoph Hellwig
2019-08-18 18:16 ` Gao Xiang
2019-08-18 20:14 ` Gao Xiang
2019-08-19 7:35 ` Richard Weinberger
2019-08-19 8:02 ` Gao Xiang
2019-08-19 10:34 ` [PATCH 0/6] staging: erofs: first stage of corrupted compressed images Gao Xiang
2019-08-19 10:34 ` [PATCH 1/6] staging: erofs: some compressed cluster should be submitted for corrupted images Gao Xiang
2019-08-19 14:36 ` Chao Yu
2019-08-19 14:36 ` Chao Yu
2019-08-19 14:39 ` Chao Yu
2019-08-19 14:39 ` Chao Yu
2019-08-19 10:34 ` [PATCH 2/6] staging: erofs: cannot set EROFS_V_Z_INITED_BIT if fill_inode_lazy fails Gao Xiang
2019-08-19 14:43 ` Chao Yu
2019-08-19 14:43 ` Chao Yu
2019-08-19 10:34 ` [PATCH 3/6] staging: erofs: add two missing erofs_workgroup_put for corrupted images Gao Xiang
2019-08-19 14:40 ` Chao Yu
2019-08-19 14:40 ` Chao Yu
2019-08-19 10:34 ` [PATCH 4/6] staging: erofs: avoid loop in submit chains Gao Xiang
2019-08-19 14:50 ` Chao Yu
2019-08-19 14:50 ` Chao Yu
2019-08-19 10:34 ` [PATCH 5/6] staging: erofs: detect potential multiref due to corrupted images Gao Xiang
2019-08-19 14:57 ` Chao Yu
2019-08-19 14:57 ` Chao Yu
2019-08-21 2:19 ` Greg Kroah-Hartman
2019-08-21 14:01 ` [PATCH v2 " Gao Xiang
2019-08-21 14:24 ` Chao Yu
2019-08-19 10:34 ` [PATCH 6/6] staging: erofs: avoid endless loop of invalid lookback distance 0 Gao Xiang
2019-08-19 14:58 ` Chao Yu
2019-08-19 14:58 ` Chao Yu
2019-08-19 16:09 ` [PATCH] erofs: move erofs out of staging Darrick J. Wong
2019-08-19 20:30 ` Gao Xiang via Linux-erofs
2019-08-20 0:55 ` Qu Wenruo
2019-08-20 1:55 ` Gao Xiang
2019-08-20 2:24 ` Chao Yu
2019-08-20 2:38 ` Qu Wenruo
2019-08-20 7:15 ` Chao Yu
2019-08-20 8:46 ` Qu Wenruo
2019-08-21 2:12 ` Chao Yu
2019-08-20 15:56 ` Theodore Y. Ts'o
2019-08-20 16:35 ` Gao Xiang via Linux-erofs
2019-08-21 0:51 ` Theodore Y. Ts'o
2019-08-21 1:34 ` Chao Yu
2019-08-21 1:48 ` Darrick J. Wong [this message]
2019-08-21 1:57 ` Chao Yu
2019-08-20 3:33 ` Miao Xie
2019-08-20 3:46 ` Gao Xiang
2019-08-20 6:04 ` Qu Wenruo
2019-08-20 6:22 ` Gao Xiang
2019-08-19 7:37 ` Richard Weinberger
2019-08-18 17:43 ` Theodore Y. Ts'o
2019-08-18 16:03 ` Gao Xiang
2019-08-18 17:06 ` Richard Weinberger
2019-08-18 17:46 ` Theodore Y. Ts'o
2019-08-18 18:00 ` Richard Weinberger
2019-08-18 18:31 ` Gao Xiang
2019-08-18 9:28 ` Gao Xiang
2019-08-19 5:28 ` [PATCH] erofs: Use common kernel logging style Joe Perches
2019-08-19 5:52 ` Gao Xiang
2019-08-19 5:47 ` Joe Perches
2019-08-19 6:08 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190821014818.GB1037422@magnolia \
--to=darrick.wong@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=david@fromorbit.com \
--cc=devel@driverdev.osuosl.org \
--cc=dsterba@suse.cz \
--cc=ebiggers@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miaoxie@huawei.com \
--cc=pavel@denx.de \
--cc=quwenruo.btrfs@gmx.com \
--cc=richard@nod.at \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=yuchao0@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).