From: Mimi Zohar <zohar@linux.ibm.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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 09:44:39 -0500 [thread overview]
Message-ID: <1549982679.12743.248.camel@linux.ibm.com> (raw)
In-Reply-To: <20190212051237.GQ23000@mit.edu>
> At that point, the merkle tree thing ends up fairly equivalent to
the
> > IMA "measurement" thing, with the exception that the filesystem *may*
> > optimize it to be long-term. Hmm?
>
> Well, except that it's just a less efficient way of doing IMA
> "measurement" (if the file system doesn't support Merkle tree
> storage).
>
> So adding that complexity is, in my view, not really worth it, since I
> very much doubt anyone would use a slower scheme. I think the much
> better model is that fsverity is for file system where you can store
> the Merkle tree (and it's really not that hard for most file systems
> to store it); and if you are using a file system which doesn't, use
> IMA in good health.
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.
Mimi
next prev parent reply other threads:[~2019-02-12 14:45 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 [this message]
2019-02-12 17:11 ` Theodore Y. Ts'o
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=1549982679.12743.248.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--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=tytso@mit.edu \
/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).