From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Theodore Y. Ts'o" Subject: Re: [PATCH v2 01/12] fs-verity: add a documentation file Date: Wed, 19 Dec 2018 14:30:05 -0500 Message-ID: <20181219193005.GB6889@mit.edu> References: <20181219071420.GC2628@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20181219071420.GC2628@infradead.org> <20181219021953.GD31274@dastard> Sender: linux-kernel-owner@vger.kernel.org To: Dave Chinner , Christoph Hellwig Cc: "Darrick J. Wong" , Eric Biggers , linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, Jaegeuk Kim , Victor Hsieh , Chandan Rajendra , Linus Torvalds List-Id: linux-f2fs-devel.lists.sourceforge.net On Wed, Dec 19, 2018 at 01:19:53PM +1100, Dave Chinner wrote: > Putting metadata in user files beyond EOF doesn't work with XFS's > post-EOF speculative allocation algorithms. > > i.e. Filesystem design/algorithms often assume that the region > beyond EOF in user files is a write-only region. e.g. We can allow > extents beyond EOF to be uninitialised because they are in a write > only region of the file and so there's no possibility of stale data > exposure. Unfortunately, putting filesystem/security metadata beyond > EOF breaks these assumptions - it's no longer a write-only region. On Tue, Dec 18, 2018 at 11:14:20PM -0800, Christoph Hellwig wrote: > Filesystems already use blocks beyond EOF for preallocation, either > speculative by the file system itself, or explicitly by the user with > fallocate. I bet you will run into bugs with your creative abuse > sooner or later. Indepnd of that the interface simply is gross, which > is enough of a reason not to merge it. Both of these concerns aren't applicable for fs-verity because the entire file will be read-only. So there will be no preallocation or fallocation going on --- or allowed --- for a file which is protected by fs-verity. Since no writes are allowed at all, it won't break any file systems' assumptions about "write-only regions". As far as whether it's "gross" --- that's a taste question, and I happen to think it's more "clever" than "gross". It allows for a very simple implementation, *leveraging* the fact that the file will never change --- and especially, grow in length. So why not use the space after EOF? The alternative requires adding Solaris-style alternate data streams support. Whether or not ADS is a good idea or just an invitation to malware authors[1] is something which can be debated, but my position is it's unnecessary given the requirements of fs-verity. And avoiding such complexity is a *good* thing, not a bad thing. [1] https://www.deepinstinct.com/2018/06/12/the-abuse-of-alternate-data-stream-hasnt-disappeared/ - Ted