From: "Theodore Y. Ts'o" <email@example.com> To: Linus Torvalds <firstname.lastname@example.org> Cc: Dave Chinner <email@example.com>, Christoph Hellwig <firstname.lastname@example.org>, "Darrick J. Wong" <email@example.com>, Eric Biggers <firstname.lastname@example.org>, <email@example.com>, linux-fsdevel <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org> Subject: Proposal: Yet another possible fs-verity interface Date: Wed, 6 Feb 2019 22:11:01 -0500 [thread overview] Message-ID: <20190207031101.GA7387@mit.edu> (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. Cheers, - Ted
next 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: 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=20190207031101.GA7387@mit.edu \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Proposal: Yet another possible fs-verity interface' \ /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
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).