From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D51D1C3A59F for ; Sun, 18 Aug 2019 17:29:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AB1022183E for ; Sun, 18 Aug 2019 17:29:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566149383; bh=PgJleJMkSwlg249xRQ3F/CLBlnJ55j1fqyWspV/sxSo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=nuaJ4KEffCgN1xkSHXVEGRPqa6qMzQ3lPafih+ao3YnA6x9Ce/Xd3zd5QLdo48/HU B2PPknX1FfKHC+xtoWmCYEGvt/ZoEpx/WWIqmNFogpd1hTtzjFeDTzo/lsNFOqLsEm KJzFlC2fRYWnGgsCGdIv95JL4+/PZIWS3W/zJExI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726937AbfHRR3m (ORCPT ); Sun, 18 Aug 2019 13:29:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:40250 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725786AbfHRR3m (ORCPT ); Sun, 18 Aug 2019 13:29:42 -0400 Received: from sol.localdomain (c-24-5-143-220.hsd1.ca.comcast.net [24.5.143.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 480E22146E; Sun, 18 Aug 2019 17:29:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566149381; bh=PgJleJMkSwlg249xRQ3F/CLBlnJ55j1fqyWspV/sxSo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FekiGl/L6shXdxivYe+rkyONVdHXfQ6Afmbfr/fNBY+CHkNu25IEPWPt56UlqUHno bFpMcqrtl7K2u7xAZD9UH+7fT8gKqlVaSimOuXQXrY2NSWuSlGZnV8E0f/h03HFPB1 o0+oYsbdFDrx6uD30QvqnfFZ6AXv0QVAO+i0O/fc= Date: Sun, 18 Aug 2019 10:29:38 -0700 From: Eric Biggers To: Christoph Hellwig Cc: "Theodore Y. Ts'o" , Richard Weinberger , Greg Kroah-Hartman , Gao Xiang , Jan Kara , Chao Yu , Dave Chinner , David Sterba , Miao Xie , devel , Stephen Rothwell , Darrick , Amir Goldstein , linux-erofs , Al Viro , Jaegeuk Kim , linux-kernel , Li Guifu , Fang Wei , Pavel Machek , linux-fsdevel , Andrew Morton , torvalds Subject: Re: [PATCH] erofs: move erofs out of staging Message-ID: <20190818172938.GA14413@sol.localdomain> Mail-Followup-To: Christoph Hellwig , "Theodore Y. Ts'o" , Richard Weinberger , Greg Kroah-Hartman , Gao Xiang , Jan Kara , Chao Yu , Dave Chinner , David Sterba , Miao Xie , devel , Stephen Rothwell , Darrick , Amir Goldstein , linux-erofs , Al Viro , Jaegeuk Kim , linux-kernel , Li Guifu , Fang Wei , Pavel Machek , linux-fsdevel , Andrew Morton , torvalds References: <20190817233843.GA16991@hsiangkao-HP-ZHAN-66-Pro-G1> <1405781266.69008.1566116210649.JavaMail.zimbra@nod.at> <20190818084521.GA17909@hsiangkao-HP-ZHAN-66-Pro-G1> <1133002215.69049.1566119033047.JavaMail.zimbra@nod.at> <20190818090949.GA30276@kroah.com> <790210571.69061.1566120073465.JavaMail.zimbra@nod.at> <20190818151154.GA32157@mit.edu> <20190818155812.GB13230@infradead.org> <20190818161638.GE1118@sol.localdomain> <20190818162201.GA16269@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190818162201.GA16269@infradead.org> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 18, 2019 at 09:22:01AM -0700, Christoph Hellwig wrote: > 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). Not sure what you're even disagreeing with, as I *do* expect new filesystems to be held to a high standard, and to be written with the assumption that the on-disk data may be corrupted or malicious. We just can't expect the bar to be so high (e.g. no bugs) that it's never been attained by *any* filesystem even after years/decades of active development. If the developers were careful, the code generally looks robust, and they are willing to address such bugs as they are found, realistically that's as good as we can expect to get... - Eric