archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <>
To: Linus Torvalds <>
Cc: Dave Chinner <>,
	Christoph Hellwig <>,
	"Darrick J. Wong" <>,
	Eric Biggers <>,
	linux-fsdevel <>,
Subject: Proposal: Yet another possible fs-verity interface
Date: Wed, 6 Feb 2019 22:11:01 -0500	[thread overview]
Message-ID: <> (raw)

After doing a lot of thinking and conferring with the other fs-verity
developers, our current thinking is to simply move the Merkle tree
creation into the kernel.  The upside of doing this is it completely
bypasses all of the complaints about how to transfer the Merkle tree
from userspace to the kernel.  It avoids the complexities of
redesigning the xattr interface, or creating a magic fd which could be
lseek'ed, mmap'ed, read, written, etc. to transfer the Merkle tree,
etc.  Calculating the Merkle tree from a code complexity is going to
be simpler.

The downside of this approach is that it can take a lot of CPU time in
the kernel (it would have to do be done in a kernel thread).  An extra
bit of complication is worrying about how to handle the situation
where if the kernel crashes.  The current thinking is that the ioctl
which enable fs-verity protection on the file will make sure that the
file descriptor is not otherwise opened for writing, and then set the
immutable bit.  Once the Merkle tree is written and finalized, the
fs-verity flag would be set and the immutable bit would be cleared.
The exact mechanisms of crash recovery would be file-system dependent,
and TBD, but would probably rely on the journalling mechanisms
available (e.g., ext4 might rely on the orphan list; f2fs might use
copy-on-write semantics; etc.)

This effectively moves the complexity from the interface (which is
where we seem to be getting hung up) to the implementation, but as
stated above, the actual code to create a Merkle tree is fairly simple.

Hopefully this will cut through the current complaints of the
fs-verity API.


					- Ted

             reply	other threads:[~2019-02-07 16:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-07  3:11 Theodore Y. Ts'o [this message]
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

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: Proposal: Yet another possible fs-verity interface' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).