From: Christoph Hellwig <hch@infradead.org> To: Christoph Hellwig <hch@infradead.org>, "Theodore Y. Ts'o" <tytso@mit.edu>, Richard Weinberger <richard@nod.at>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Gao Xiang <hsiangkao@aol.com>, 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>, 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: Sun, 18 Aug 2019 09:22:01 -0700 [thread overview] Message-ID: <20190818162201.GA16269@infradead.org> (raw) In-Reply-To: <20190818161638.GE1118@sol.localdomain> On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote: > Ted's observation was about maliciously-crafted filesystems, though, so > integrity-only features such as metadata checksums are irrelevant. Also the > filesystem version is irrelevant; anything accepted by the kernel code (even if I think allowing users to mount file systems (any of ours) without privilege is a rather bad idea. But that doesn't mean we should not be as robust as we can. Optionally disabling support for legacy formats at compile and/or runtime is something we should actively look into as well. > it's legacy/deprecated) is open attack surface. > > I personally consider it *mandatory* that we deal with this stuff. But I can > understand that we don't do a good job at it, so we shouldn't hold a new > filesystem to an unfairly high standard relative to other filesystems... I very much disagree. We can't really force anyone to fix up old file systems. But we can very much hold new ones to (slightly) higher standards. Thats the only way to get the average quality up. Some as for things like code style - we can't magically fix up all old stuff, but we can and usually do hold new code to higher standards. (Often not to standards as high as I'd personally prefer, btw).
WARNING: multiple messages have this Message-ID (diff)
From: hch@infradead.org (Christoph Hellwig) Subject: [PATCH] erofs: move erofs out of staging Date: Sun, 18 Aug 2019 09:22:01 -0700 [thread overview] Message-ID: <20190818162201.GA16269@infradead.org> (raw) In-Reply-To: <20190818161638.GE1118@sol.localdomain> On Sun, Aug 18, 2019@09:16:38AM -0700, Eric Biggers wrote: > Ted's observation was about maliciously-crafted filesystems, though, so > integrity-only features such as metadata checksums are irrelevant. Also the > filesystem version is irrelevant; anything accepted by the kernel code (even if I think allowing users to mount file systems (any of ours) without privilege is a rather bad idea. But that doesn't mean we should not be as robust as we can. Optionally disabling support for legacy formats at compile and/or runtime is something we should actively look into as well. > it's legacy/deprecated) is open attack surface. > > I personally consider it *mandatory* that we deal with this stuff. But I can > understand that we don't do a good job at it, so we shouldn't hold a new > filesystem to an unfairly high standard relative to other filesystems... I very much disagree. We can't really force anyone to fix up old file systems. But we can very much hold new ones to (slightly) higher standards. Thats the only way to get the average quality up. Some as for things like code style - we can't magically fix up all old stuff, but we can and usually do hold new code to higher standards. (Often not to standards as high as I'd personally prefer, btw).
next prev parent reply other threads:[~2019-08-18 16:22 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 [this message] 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 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=20190818162201.GA16269@infradead.org \ --to=hch@infradead.org \ --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=hsiangkao@aol.com \ --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.