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
