From: Eric Biggers <ebiggers@kernel.org>
To: Chuck Lever <chucklever@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-integrity@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-kernel@vger.kernel.org,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Michael Halcrow <mhalcrow@google.com>,
Victor Hsieh <victorhsieh@google.com>
Subject: Re: [RFC PATCH 01/10] fs-verity: add setup code, UAPI, and Kconfig
Date: Sun, 26 Aug 2018 10:17:14 -0700 [thread overview]
Message-ID: <20180826171713.GB728@sol.localdomain> (raw)
In-Reply-To: <815EEE5D-D90F-4E97-A33E-D33D868B962B@gmail.com>
Hi Chuck,
On Sun, Aug 26, 2018 at 12:22:08PM -0400, Chuck Lever wrote:
> Hi Eric-
>
> Context: I'm working on IMA support for NFSv4, and would like to
> use fs-verity (or some Merkle tree-like mechanism) eventually to
> help address the performance impacts of using IMA with large NFS
> files.
>
>
> > On Aug 24, 2018, at 12:16 PM, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > From: Eric Biggers <ebiggers@google.com>
> >
> > fs-verity is a filesystem feature that provides efficient, transparent
> > integrity verification and authentication of read-only files. It uses a
> > dm-verity like mechanism at the file level: a Merkle tree hidden past
> > the end of the file is used to verify any block in the file in
> > log(filesize) time. It is implemented mainly by helper functions in
> > fs/verity/ that will be shared by multiple filesystems.
>
> This description suggests that the only way fs-verity can work is
> by placing the Merkle tree data after EOF. Further, this organi-
> zation is exposed to user space, making it a fixed part of the
> fs-verity kernel/user space API.
>
> Remote filesystems -- esp. NFS -- would prefer to manage the Merkle
> tree data in other ways. The NFSv4 protocol, for example, supports
> named streams (as some other filesystems do), and could store the
> Merkle trees in those. Or, a new pNFS layout type could be con-
> structed where Merkle trees are stored separately from a file's
> content -- perhaps even on a separate file server.
>
> File servers can store this data as the servers' local filesystems
> require.
>
> Sharing how the Merkle tree is created and used is sensible, but
> IMHO the filesystem implementations should be allowed to store this
> tree however they find convenient. The Merkle trees should be
> exposed via a clean API, not as part of the file's content.
>
There has also been discussion with this on the thread for patch 02/10.
"A Merkle tree hidden past the end of the file" describes how ext4 and f2fs are
proposed to implement it, and it describes the file format expected by
FS_IOC_ENABLE_VERITY. But, at FS_IOC_ENABLE_VERITY time, a filesystem could
copy the verity metadata to somewhere else if it wanted, e.g. into a file
stream, and then truncate the file to its original size.
Afterwards, fs-verity doesn't really care where the metadata is stored.
Currently it does actually assume it's beyond EOF since it calls
read_mapping_page() directly, but that could be replaced at any time with
indirection via a method fsverity_operations.read_metadata_page().
We actually had such a method originally, but it turned out to be unnecessary
for ext4 and f2fs, so I had dropped it for now.
I will make this clearer in the next revision of the patchset, and maybe even
consider reintroducing ->read_metadata_page() to make it clear that filesystems
don't necessarily have to store the metadata beyond EOF.
Thanks,
- Eric
next prev parent reply other threads:[~2018-08-26 21:00 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-24 16:16 [RFC PATCH 00/10] fs-verity: filesystem-level integrity protection Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 01/10] fs-verity: add setup code, UAPI, and Kconfig Eric Biggers
2018-08-24 17:28 ` Randy Dunlap
2018-08-24 17:42 ` Colin Walters
2018-08-24 22:45 ` Theodore Y. Ts'o
2018-08-25 4:48 ` Eric Biggers
2018-09-14 13:15 ` Colin Walters
2018-09-14 16:21 ` Eric Biggers
2018-09-15 15:27 ` Theodore Y. Ts'o
2018-08-26 16:22 ` Chuck Lever
2018-08-26 17:17 ` Eric Biggers [this message]
2018-08-24 16:16 ` [RFC PATCH 02/10] fs-verity: add data verification hooks for ->readpages() Eric Biggers
2018-08-25 2:29 ` [f2fs-dev] " Gao Xiang
2018-08-25 3:45 ` Theodore Y. Ts'o
2018-08-25 4:00 ` Gao Xiang
2018-08-25 5:06 ` Theodore Y. Ts'o
2018-08-25 7:33 ` Gao Xiang
2018-08-25 7:55 ` Gao Xiang
2018-08-25 4:16 ` Eric Biggers
2018-08-25 6:31 ` Gao Xiang
2018-08-25 7:18 ` Eric Biggers
2018-08-25 7:43 ` Gao Xiang
2018-08-25 17:06 ` Theodore Y. Ts'o
2018-08-26 13:44 ` Gao Xiang
2018-09-02 2:35 ` Olof Johansson
2018-08-26 15:55 ` Chuck Lever
2018-08-26 17:04 ` Eric Biggers
2018-08-26 17:44 ` Gao Xiang
2018-08-24 16:16 ` [RFC PATCH 03/10] fs-verity: implement FS_IOC_ENABLE_VERITY ioctl Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 04/10] fs-verity: implement FS_IOC_MEASURE_VERITY ioctl Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 05/10] fs-verity: add SHA-512 support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 06/10] fs-verity: add CRC-32C support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 07/10] fs-verity: support builtin file signatures Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 08/10] ext4: add basic fs-verity support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 09/10] ext4: add fs-verity read support Eric Biggers
2018-08-24 16:16 ` [RFC PATCH 10/10] f2fs: fs-verity support Eric Biggers
2018-08-25 5:54 ` [f2fs-dev] " Chao Yu
2018-08-26 17:35 ` Eric Biggers
2018-08-27 15:54 ` Chao Yu
2018-08-28 7:27 ` Jaegeuk Kim
2018-08-28 9:20 ` Chao Yu
2018-08-28 17:01 ` Jaegeuk Kim
2018-08-29 1:22 ` Chao Yu
2018-08-29 1:43 ` Jaegeuk Kim
2018-08-31 20:05 ` [RFC PATCH 00/10] fs-verity: filesystem-level integrity protection Jan Lübbe
2018-08-31 21:39 ` 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=20180826171713.GB728@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=chucklever@gmail.com \
--cc=dmitry.kasatkin@gmail.com \
--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=mhalcrow@google.com \
--cc=victorhsieh@google.com \
--cc=zohar@linux.vnet.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).