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: <735b8d15-bcb5-b11b-07c1-0617eb1e5ce9@gmx.com>
Date:   Tue, 20 Aug 2019 16:46:03 +0800
From:   Qu Wenruo <quwenruo.btrfs@....com>
To:     Chao Yu <yuchao0@...wei.com>, Gao Xiang <hsiangkao@....com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        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

[...]
> 
> Yeah, it looks like we need searching more levels mapping to find the final
> physical block address of inode/node/data in btrfs.
> 
> IMO, in a little lazy way, we can reform and reuse existed function in
> btrfs-progs which can find the mapping info of inode/node/data according to
> specified ino or ino+pg_no.

Maybe no need to go as deep as ino.

What about just go physical bytenr? E.g. for XFS/EXT* choose a random
bytenr. Then verify if that block is used, if not, try again.

If used, check if it's metadata. If not, try again.
(feel free to corrupt data, in fact btrfs uses some data as space cache,
so it should make some sense)

If metadata, corrupt that bytenr/bytenr range in the metadata block,
regenerate checksum, call it a day and let kernel suffer.

For btrfs, just do extra physical -> logical convert in the first place,
then follow the same workflow.
It should work for any fs as long as it's on single device.

> 
>>
>> It may depends on the granularity. But definitely a good idea to do so
>> in a generic way.
>> Currently we depend on super kind student developers/reporters on such
> 
> Yup, I just guess Wen Xu may be interested in working on a generic way to fuzz
> filesystem, as I know they dig deep in filesystem code when doing fuzz.

Don't forget Yoon Jungyeon, I see more than one times he reported fuzzed
images with proper reproducer and bugzilla links.
Even using his personal mail address, not school mail address.

Those guys are really awesome!

> BTW,
> which impresses me is, constructing checkpoint by injecting one byte, and then
> write a correct recalculated checksum value on that checkpoint, making that
> checkpoint looks valid...

IIRC F2FS guys may be also investigating a similar mechanism, as they
also got a hard fight against reports from those awesome reporters.

So such fuzzed image is a new trend for fs development.

Thanks,
Qu

> 
> Thanks,
> 

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)