linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Eric Biggers <ebiggers@kernel.org>,
	<linux-fscrypt@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	<linux-ext4@vger.kernel.org>,
	<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: Proposal: Yet another possible fs-verity interface
Date: Tue, 12 Feb 2019 12:11:09 -0500	[thread overview]
Message-ID: <20190212171109.GS23000@mit.edu> (raw)
In-Reply-To: <1549982679.12743.248.camel@linux.ibm.com>

On Tue, Feb 12, 2019 at 09:44:39AM -0500, Mimi Zohar wrote:
> Ted, one of the problems with IMA is that the file hash/signature
> verification is at file open.  It isn't aware when files are brought
> in from cache.  Does fs-verity re-verify blocks as they're restored
> from cache?  For some use cases, that might justify the up front cost
> associated with building the Merkle tree.

fs-verity as designed and implemented today *only* verifies blocks as
they are read from the file system.  The Merkle tree is stored on
disk, and we don't verify all of the pages at open time.  That's the
whole *point* of fs-verity.  So when you say re-verify, that's simply
not correct.

Could we change it so that there is an optional mode where Merkle tree
is kept pinned in memory and recalculated the first time the file is
opened?  I suppose; the overhead is "only" 0.8% of the file size.  But
for big files, it adds up; and if you never use most of the file (say,
it's an unstripped executable with debugging information), you end up
paying twice --- once to calculate the Merkle tree (in CPU and Disk
time wasted), and a second time by pinning the full Merkle tree in
memory.  Also, it leaves open the question of how aggressively we drop
the Merkle tree once the file is closed.  Do we wait until the inode
gets purged from the inode cache?  That might pin the memory for way
too long.  Do we drop the Merkle tree the moment the inode's open
count goes to zero?

If it's not too hard to add, and if we're generating the Merkle tree
in the kernel, it's something we could do, I suppose.  But it's not
something *we're* going to use, so I'm not terribly excited about
wasting effort on work that just bitrots if no one is actually going
to use it in that way.

If you are willing to commit that IMA will use it in that way, and
you're fairly sure IMA users are going to be willing to pay the memory
tax, we can look into adding it, if it's doesn't add too much effort
on our part.  I just want to be clear that this is a "yes, we would
definitely use such a thing", as opposed to, "it might be nice...."

Cheers,

					- Ted

      reply	other threads:[~2019-02-12 17:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-07  3:11 Proposal: Yet another possible fs-verity interface Theodore Y. Ts'o
2019-02-08 19:10 ` James Bottomley
2019-02-09 20:38 ` Linus Torvalds
2019-02-10 14:06   ` Mimi Zohar
2019-02-12  5:31     ` Theodore Y. Ts'o
2019-02-12 13:06       ` Mimi Zohar
2019-02-12 17:24         ` Theodore Y. Ts'o
2019-02-12 18:42           ` [f2fs-dev] " Eric Biggers
2019-02-12  5:12   ` Theodore Y. Ts'o
2019-02-12 14:44     ` Mimi Zohar
2019-02-12 17:11       ` Theodore Y. Ts'o [this message]

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=20190212171109.GS23000@mit.edu \
    --to=tytso@mit.edu \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=ebiggers@kernel.org \
    --cc=hch@infradead.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=torvalds@linux-foundation.org \
    --cc=zohar@linux.ibm.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).