From: Gao Xiang <hsiangkao@aol.com> To: "Theodore Y. Ts'o" <tytso@mit.edu> Cc: Richard Weinberger <richard@nod.at>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jan Kara <jack@suse.cz>, Chao Yu <yuchao0@huawei.com>, Dave Chinner <david@fromorbit.com>, David Sterba <dsterba@suse.cz>, Miao Xie <miaoxie@huawei.com>, devel <devel@driverdev.osuosl.org>, Stephen Rothwell <sfr@canb.auug.org.au>, Darrick <darrick.wong@oracle.com>, Christoph Hellwig <hch@infradead.org>, Amir Goldstein <amir73il@gmail.com>, linux-erofs <linux-erofs@lists.ozlabs.org>, Al Viro <viro@zeniv.linux.org.uk>, Jaegeuk Kim <jaegeuk@kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Li Guifu <bluce.liguifu@huawei.com>, Fang Wei <fangwei1@huawei.com>, Pavel Machek <pavel@denx.de>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Andrew Morton <akpm@linux-foundation.org>, torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH] erofs: move erofs out of staging Date: Mon, 19 Aug 2019 00:03:11 +0800 [thread overview] Message-ID: <20190818160305.GA31588@hsiangkao-HP-ZHAN-66-Pro-G1> (raw) In-Reply-To: <20190818151154.GA32157@mit.edu> Hi Ted, On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote: > On Sun, Aug 18, 2019 at 11:21:13AM +0200, Richard Weinberger wrote: > > > Not to say that erofs shouldn't be worked on to fix these kinds of > > > issues, just that it's not an unheard of thing to trust the disk image. > > > Especially for the normal usage model of erofs, where the whole disk > > > image is verfied before it is allowed to be mounted as part of the boot > > > process. > > > > For normal use I see no problem at all. > > I fear distros that try to mount anything you plug into your USB. > > > > At least SUSE already blacklists erofs: > > https://github.com/openSUSE/suse-module-tools/blob/master/suse-module-tools.spec#L24 > > Note that of the mainstream file systems, ext4 and xfs don't guarantee > that it's safe to blindly take maliciously provided file systems, such > as those provided by a untrusted container, and mount it on a file > system without problems. As I recall, one of the XFS developers > described file system fuzzing reports as a denial of service attack on > the developers. And on the ext4 side, while I try to address them, it > is by no means considered a high priority work item, and I don't > consider fixes of fuzzing reports to be worthy of coordinated > disclosure or a high priority bug to fix. (I have closed more bugs in > this area than XFS has, although that may be that ext4 started with > more file system format bugs than XFS; however given the time to first > bug in 2017 using American Fuzzy Lop[1] being 5 seconds for btrfs, 10 > seconds for f2fs, 25 seconds for reiserfs, 4 minutes for ntfs, 1h45m > for xfs, and 2h for ext4, that seems unlikely.) > > [1] https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf > > So holding a file system like EROFS to a higher standard than say, > ext4, xfs, or btrfs hardly seems fair. There seems to be a very > unfortunate tendancy for us to hold new file systems to impossibly > high standards, when in fact, adding a file system to Linux should > not, in my opinion, be a remarkable event. We have a huge number of > them already, many of which are barely maintained and probably have > far worse issues than file systems trying to get into the clubhouse. > > If a file system is requesting core changes to the VM or block layers, > sure, we should care about the interfaces. But this nitpicking about > whether or not a file system can be trusted in what I consider to be > COMPLETELY INSANE CONTAINER USE CASES is really not fair. Thanks for your kind reply and understanding... Yes, EROFS is now still like a little baby, and what I can do is to write more code to make it grown up... but I personally cannot write bug-free code all the time (because sometimes I could be in a low mood...) In the past year, we already adds many error handling path for corrupted images and handles all BUG_ONs in a more proper way... we are doing our best... Our team will continue focusing on all bug reports from external / internal sources and fix them all in time. and for more wider scenerios, I'd like to build an autofuzzer tools based on erofs-utils to make EROFS more strong as one of the next step. Thanks, Gao Xiang > > Cheers, > > - Ted
WARNING: multiple messages have this Message-ID (diff)
From: hsiangkao@aol.com (Gao Xiang) Subject: [PATCH] erofs: move erofs out of staging Date: Mon, 19 Aug 2019 00:03:11 +0800 [thread overview] Message-ID: <20190818160305.GA31588@hsiangkao-HP-ZHAN-66-Pro-G1> (raw) In-Reply-To: <20190818151154.GA32157@mit.edu> Hi Ted, On Sun, Aug 18, 2019@11:11:54AM -0400, Theodore Y. Ts'o wrote: > On Sun, Aug 18, 2019@11:21:13AM +0200, Richard Weinberger wrote: > > > Not to say that erofs shouldn't be worked on to fix these kinds of > > > issues, just that it's not an unheard of thing to trust the disk image. > > > Especially for the normal usage model of erofs, where the whole disk > > > image is verfied before it is allowed to be mounted as part of the boot > > > process. > > > > For normal use I see no problem at all. > > I fear distros that try to mount anything you plug into your USB. > > > > At least SUSE already blacklists erofs: > > https://github.com/openSUSE/suse-module-tools/blob/master/suse-module-tools.spec#L24 > > Note that of the mainstream file systems, ext4 and xfs don't guarantee > that it's safe to blindly take maliciously provided file systems, such > as those provided by a untrusted container, and mount it on a file > system without problems. As I recall, one of the XFS developers > described file system fuzzing reports as a denial of service attack on > the developers. And on the ext4 side, while I try to address them, it > is by no means considered a high priority work item, and I don't > consider fixes of fuzzing reports to be worthy of coordinated > disclosure or a high priority bug to fix. (I have closed more bugs in > this area than XFS has, although that may be that ext4 started with > more file system format bugs than XFS; however given the time to first > bug in 2017 using American Fuzzy Lop[1] being 5 seconds for btrfs, 10 > seconds for f2fs, 25 seconds for reiserfs, 4 minutes for ntfs, 1h45m > for xfs, and 2h for ext4, that seems unlikely.) > > [1] https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf > > So holding a file system like EROFS to a higher standard than say, > ext4, xfs, or btrfs hardly seems fair. There seems to be a very > unfortunate tendancy for us to hold new file systems to impossibly > high standards, when in fact, adding a file system to Linux should > not, in my opinion, be a remarkable event. We have a huge number of > them already, many of which are barely maintained and probably have > far worse issues than file systems trying to get into the clubhouse. > > If a file system is requesting core changes to the VM or block layers, > sure, we should care about the interfaces. But this nitpicking about > whether or not a file system can be trusted in what I consider to be > COMPLETELY INSANE CONTAINER USE CASES is really not fair. Thanks for your kind reply and understanding... Yes, EROFS is now still like a little baby, and what I can do is to write more code to make it grown up... but I personally cannot write bug-free code all the time (because sometimes I could be in a low mood...) In the past year, we already adds many error handling path for corrupted images and handles all BUG_ONs in a more proper way... we are doing our best... Our team will continue focusing on all bug reports from external / internal sources and fix them all in time. and for more wider scenerios, I'd like to build an autofuzzer tools based on erofs-utils to make EROFS more strong as one of the next step. Thanks, Gao Xiang > > Cheers, > > - Ted
next prev parent reply other threads:[~2019-08-18 16:03 UTC|newest] Thread overview: 170+ 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 8:23 ` Gao Xiang 2019-08-17 21:19 ` Richard Weinberger 2019-08-17 21:19 ` Richard Weinberger 2019-08-17 22:07 ` Gao Xiang 2019-08-17 22:07 ` Gao Xiang 2019-08-17 23:25 ` Richard Weinberger 2019-08-17 23:25 ` Richard Weinberger 2019-08-17 23:38 ` Gao Xiang 2019-08-17 23:38 ` Gao Xiang 2019-08-18 0:04 ` Gao Xiang 2019-08-18 0:04 ` Gao Xiang 2019-08-18 0:52 ` Gao Xiang 2019-08-18 0:52 ` Gao Xiang 2019-08-18 8:16 ` Richard Weinberger 2019-08-18 8:16 ` Richard Weinberger 2019-08-18 8:45 ` Gao Xiang 2019-08-18 8:45 ` Gao Xiang 2019-08-18 9:03 ` Richard Weinberger 2019-08-18 9:03 ` Richard Weinberger 2019-08-18 9:09 ` Greg Kroah-Hartman 2019-08-18 9:09 ` Greg Kroah-Hartman 2019-08-18 9:21 ` Richard Weinberger 2019-08-18 9:21 ` Richard Weinberger 2019-08-18 10:12 ` Chao Yu 2019-08-18 10:12 ` Chao Yu 2019-08-18 15:11 ` Theodore Y. Ts'o 2019-08-18 15:11 ` Theodore Y. Ts'o 2019-08-18 15:58 ` Christoph Hellwig 2019-08-18 15:58 ` Christoph Hellwig 2019-08-18 16:16 ` Eric Biggers 2019-08-18 16:16 ` Eric Biggers 2019-08-18 16:22 ` Christoph Hellwig 2019-08-18 16:22 ` Christoph Hellwig 2019-08-18 16:33 ` Gao Xiang 2019-08-18 16:33 ` Gao Xiang 2019-08-18 17:29 ` Eric Biggers 2019-08-18 17:29 ` Eric Biggers 2019-08-18 17:47 ` Christoph Hellwig 2019-08-18 17:47 ` Christoph Hellwig 2019-08-18 18:16 ` Gao Xiang 2019-08-18 18:16 ` Gao Xiang 2019-08-18 20:14 ` Gao Xiang 2019-08-18 20:14 ` Gao Xiang 2019-08-19 7:35 ` Richard Weinberger 2019-08-19 7:35 ` Richard Weinberger 2019-08-19 8:02 ` Gao Xiang 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 ` 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 10:34 ` Gao Xiang 2019-08-19 14:36 ` Chao Yu 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 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 10:34 ` Gao Xiang 2019-08-19 14:43 ` Chao Yu 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 10:34 ` Gao Xiang 2019-08-19 14:40 ` Chao Yu 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 10:34 ` Gao Xiang 2019-08-19 14:50 ` Chao Yu 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 10:34 ` Gao Xiang 2019-08-19 14:57 ` Chao Yu 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 2:19 ` Greg Kroah-Hartman 2019-08-21 2:19 ` Greg Kroah-Hartman 2019-08-21 14:01 ` [PATCH v2 " Gao Xiang 2019-08-21 14:01 ` Gao Xiang 2019-08-21 14:24 ` Chao Yu 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 10:34 ` Gao Xiang 2019-08-19 14:58 ` Chao Yu 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 16:09 ` Darrick J. Wong 2019-08-19 16:09 ` Darrick J. Wong 2019-08-19 20:30 ` Gao Xiang 2019-08-19 20:30 ` Gao Xiang via Linux-erofs 2019-08-19 20:30 ` Gao Xiang 2019-08-20 0:55 ` Qu Wenruo 2019-08-20 0:55 ` Qu Wenruo 2019-08-20 0:55 ` Qu Wenruo 2019-08-20 1:55 ` Gao Xiang 2019-08-20 1:55 ` Gao Xiang 2019-08-20 1:55 ` Gao Xiang 2019-08-20 2:24 ` Chao Yu 2019-08-20 2:24 ` Chao Yu 2019-08-20 2:24 ` Chao Yu 2019-08-20 2:38 ` Qu Wenruo 2019-08-20 2:38 ` Qu Wenruo 2019-08-20 2:38 ` Qu Wenruo 2019-08-20 7:15 ` Chao Yu 2019-08-20 7:15 ` Chao Yu 2019-08-20 7:15 ` Chao Yu 2019-08-20 8:46 ` Qu Wenruo 2019-08-20 8:46 ` Qu Wenruo 2019-08-20 8:46 ` Qu Wenruo 2019-08-21 2:12 ` Chao Yu 2019-08-21 2:12 ` Chao Yu 2019-08-21 2:12 ` Chao Yu 2019-08-20 15:56 ` Theodore Y. Ts'o 2019-08-20 15:56 ` Theodore Y. Ts'o 2019-08-20 15:56 ` Theodore Y. Ts'o 2019-08-20 16:35 ` Gao Xiang 2019-08-20 16:35 ` Gao Xiang via Linux-erofs 2019-08-20 16:35 ` Gao Xiang 2019-08-21 0:51 ` Theodore Y. Ts'o 2019-08-21 0:51 ` Theodore Y. Ts'o 2019-08-21 0:51 ` Theodore Y. Ts'o 2019-08-21 1:34 ` Chao Yu 2019-08-21 1:34 ` Chao Yu 2019-08-21 1:48 ` Darrick J. Wong 2019-08-21 1:48 ` Darrick J. Wong 2019-08-21 1:48 ` Darrick J. Wong 2019-08-21 1:57 ` Chao Yu 2019-08-21 1:57 ` Chao Yu 2019-08-21 1:57 ` Chao Yu 2019-08-20 3:33 ` Miao Xie 2019-08-20 3:33 ` Miao Xie 2019-08-20 3:33 ` Miao Xie 2019-08-20 3:46 ` Gao Xiang 2019-08-20 3:46 ` Gao Xiang 2019-08-20 3:46 ` Gao Xiang 2019-08-20 6:04 ` Qu Wenruo 2019-08-20 6:04 ` Qu Wenruo 2019-08-20 6:04 ` Qu Wenruo 2019-08-20 6:22 ` Gao Xiang 2019-08-20 6:22 ` Gao Xiang 2019-08-20 6:22 ` Gao Xiang 2019-08-19 7:37 ` Richard Weinberger 2019-08-19 7:37 ` Richard Weinberger 2019-08-18 17:43 ` Theodore Y. Ts'o 2019-08-18 17:43 ` Theodore Y. Ts'o 2019-08-18 16:03 ` Gao Xiang [this message] 2019-08-18 16:03 ` Gao Xiang 2019-08-18 17:06 ` Richard Weinberger 2019-08-18 17:06 ` Richard Weinberger 2019-08-18 17:46 ` Theodore Y. Ts'o 2019-08-18 17:46 ` Theodore Y. Ts'o 2019-08-18 18:00 ` Richard Weinberger 2019-08-18 18:00 ` Richard Weinberger 2019-08-18 18:31 ` Gao Xiang 2019-08-18 18:31 ` Gao Xiang 2019-08-18 9:28 ` 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:28 ` Joe Perches 2019-08-19 5:52 ` Gao Xiang 2019-08-19 5:52 ` Gao Xiang 2019-08-19 5:47 ` Joe Perches 2019-08-19 5:47 ` Joe Perches 2019-08-19 6:08 ` Gao Xiang 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=20190818160305.GA31588@hsiangkao-HP-ZHAN-66-Pro-G1 \ --to=hsiangkao@aol.com \ --cc=akpm@linux-foundation.org \ --cc=amir73il@gmail.com \ --cc=bluce.liguifu@huawei.com \ --cc=darrick.wong@oracle.com \ --cc=david@fromorbit.com \ --cc=devel@driverdev.osuosl.org \ --cc=dsterba@suse.cz \ --cc=fangwei1@huawei.com \ --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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.