linux-kernel - Re: [PATCH] erofs: move erofs out of staging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190820155623.GA10232@mit.edu>
Date:   Tue, 20 Aug 2019 11:56:23 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Chao Yu <yuchao0@...wei.com>
Cc:     Qu Wenruo <quwenruo.btrfs@....com>, Gao Xiang <hsiangkao@....com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Christoph Hellwig <hch@...radead.org>,
        Eric Biggers <ebiggers@...nel.org>,
        Richard Weinberger <richard@....at>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Kara <jack@...e.cz>, Dave Chinner <david@...morbit.com>,
        David Sterba <dsterba@...e.cz>, Miao Xie <miaoxie@...wei.com>,
        devel <devel@...verdev.osuosl.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Amir Goldstein <amir73il@...il.com>,
        linux-erofs <linux-erofs@...ts.ozlabs.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Li Guifu <bluce.liguifu@...wei.com>,
        Fang Wei <fangwei1@...wei.com>, Pavel Machek <pavel@...x.de>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] erofs: move erofs out of staging

On Tue, Aug 20, 2019 at 10:24:11AM +0800, Chao Yu wrote:
> Out of curiosity, it looks like every mainstream filesystem has its own
> fuzz/injection tool in their tool-set, if it's really such a generic
> requirement, why shouldn't there be a common tool to handle that, let specified
> filesystem fill the tool's callback to seek a node/block and supported fields
> can be fuzzed in inode. It can help to avoid redundant work whenever Linux
> welcomes a new filesystem....

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).

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

> > Personally speaking, debugging tool is way more important than a running
> > kernel module/fuse.
> > It's human trying to write the code, most of time is spent educating
> > code readers, thus debugging tool is way more important than dead cold code.

I personally find that having a tool like e2fsprogs' debugfs program
to be really handy.  It's useful for creating regression test images;
it's useful for debugging results from fuzzing systems like Janus;
it's useful for examining broken file systems extracted from busted
Android handsets during dogfood to root cause bugs which escaped
xfstests testing; etc.

Cheers,

						- Ted