linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Eric Biggers <ebiggers@kernel.org>,
	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 <jaegeuk@kernel.org>,
	Victor Hsieh <victorhsieh@google.com>,
	Chandan Rajendra <chandan@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2 01/12] fs-verity: add a documentation file
Date: Wed, 19 Dec 2018 14:30:05 -0500	[thread overview]
Message-ID: <20181219193005.GB6889@mit.edu> (raw)
In-Reply-To: <20181219071420.GC2628@infradead.org> <20181219021953.GD31274@dastard>

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

  reply	other threads:[~2018-12-19 19:30 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01 22:52 [PATCH v2 00/12] fs-verity: read-only file-based authenticity protection Eric Biggers
2018-11-01 22:52 ` [PATCH v2 01/12] fs-verity: add a documentation file Eric Biggers
2018-12-12  9:14   ` Christoph Hellwig
2018-12-12 20:26     ` Eric Biggers
2018-12-13 20:22       ` Christoph Hellwig
2018-12-14  4:48         ` Eric Biggers
2018-12-17 16:49           ` Christoph Hellwig
2018-12-17 18:32             ` Eric Biggers
2018-12-19  7:09               ` Christoph Hellwig
2018-12-17 20:00           ` Darrick J. Wong
2018-12-19  0:16             ` Theodore Y. Ts'o
2018-12-19  2:19               ` Dave Chinner
2018-12-19 19:30                 ` Theodore Y. Ts'o [this message]
2018-12-19 21:35                   ` Dave Chinner
2018-12-20 22:01                     ` Theodore Y. Ts'o
2018-12-21  7:04                       ` Christoph Hellwig
2018-12-21 10:06                         ` Richard Weinberger
2018-12-21 15:47                         ` Theodore Y. Ts'o
2018-12-21 15:53                           ` Matthew Wilcox
2018-12-21 16:28                             ` Theodore Y. Ts'o
2018-12-21 16:34                               ` Matthew Wilcox
2018-12-21 19:13                           ` Linus Torvalds
2018-12-22  4:17                             ` Theodore Y. Ts'o
2018-12-22 22:47                               ` Linus Torvalds
2018-12-23  4:34                                 ` Theodore Y. Ts'o
2018-12-23  4:10                               ` Matthew Wilcox
2018-12-23  4:45                                 ` Theodore Y. Ts'o
2019-01-04 20:41                                   ` Daniel Colascione
2018-12-19  7:14               ` Christoph Hellwig
2018-12-19  7:11             ` Christoph Hellwig
     [not found]               ` <CAHk-=wiB8vGbje+NgNkMZupHsZ_cqg6YEBV+ZXSF4wnywFLRHQ@mail.gmail.com>
2018-12-19  7:19                 ` Christoph Hellwig
2018-12-14  5:17         ` Theodore Y. Ts'o
2018-12-14  5:39           ` Eric Biggers
2018-12-17 16:52           ` Christoph Hellwig
2018-12-17 19:15             ` Eric Biggers
2018-12-21 16:11   ` Matthew Wilcox
2018-11-01 22:52 ` [PATCH v2 02/12] fs-verity: add setup code, UAPI, and Kconfig Eric Biggers
2018-11-01 22:52 ` [PATCH v2 03/12] fs-verity: add MAINTAINERS file entry Eric Biggers
2018-11-01 22:52 ` [PATCH v2 04/12] fs-verity: add data verification hooks for ->readpages() Eric Biggers
2018-11-01 22:52 ` [PATCH v2 05/12] fs-verity: implement FS_IOC_ENABLE_VERITY ioctl Eric Biggers
2018-11-01 22:52 ` [PATCH v2 06/12] fs-verity: implement FS_IOC_MEASURE_VERITY ioctl Eric Biggers
2018-11-01 22:52 ` [PATCH v2 07/12] fs-verity: add SHA-512 support Eric Biggers
2018-11-01 22:52 ` [PATCH v2 08/12] fs-verity: add CRC-32C support Eric Biggers
2018-11-01 22:52 ` [PATCH v2 09/12] fs-verity: support builtin file signatures Eric Biggers
2018-11-01 22:52 ` [PATCH v2 10/12] ext4: add basic fs-verity support Eric Biggers
2018-11-02  9:43   ` Chandan Rajendra
2018-11-06  1:25     ` Eric Biggers
2018-11-06  6:52       ` Chandan Rajendra
2018-11-05 21:05   ` Andreas Dilger
2018-11-06  1:11     ` Eric Biggers
2018-11-01 22:52 ` [PATCH v2 11/12] ext4: add fs-verity read support Eric Biggers
2018-11-01 22:52 ` [PATCH v2 12/12] f2fs: fs-verity support Eric Biggers

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=20181219193005.GB6889@mit.edu \
    --to=tytso@mit.edu \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=ebiggers@kernel.org \
    --cc=hch@infradead.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=victorhsieh@google.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).