From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Dave Chinner <david@fromorbit.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: A new fs-verity interface
Date: Thu, 10 Jan 2019 10:18:36 -0800 [thread overview]
Message-ID: <20190110181836.GA20467@magnolia> (raw)
Message-ID: <20190110181836.UgAa3tdJnQLnGZAgCkEUbamHLUoAJP_jCnmbk2ZF4Tc@z> (raw)
In-Reply-To: <20190110051500.GA32361@mit.edu>
On Thu, Jan 10, 2019 at 12:15:00AM -0500, Theodore Y. Ts'o wrote:
> The following approach is based in Darrick's suggestion:
>
> int ioctl(fd, FS_IOC_ENABLE_VERITY, struct fsverity_arg *arg);
>
> struct fsverity_arg {
> int fsv_donor_fd;
Explicitly sized fields and padding here, please. ISTR there are a few
arches that don't have alignment requirements which will make this
messy.
> u64 fsv_offset;
> u64 fsv_size;
You might want to allocate some reserved space for flags in case you
ever decide you need it, but otherwise it seems fine to me...
--D
> };
>
> fsv_offset and fsz_size must be a multiple of the file system block
> size. If the ioctl comples successfully, as a side effect the
> donor_fd will have a hole punch operation on the specified range. In
> other words, the equivalent of operation of fallocate(fsv_donor_fd,
> FALLOC_FL_PUNCH_HOLE, fsv_offset, fsv_size), and the file specified by
> fd will be protected using fsverity.
>
> It will be legal for fsv_donor_fd == fd, so this interface is a
> superset of the original FS_IOC_ENABLE_VERITY ioctl.
>
> This will hopefully make Christoph and Dave happy because the
> interface does not presuppose how ext4 and f2fs will implement
> fsverity behind the scenes. However, it does not forbid it, and the
> net cost is that ext4 and f2fs will have to implement code which
> transplants the blocks from the donor_fd to fd in the case where
> donor_fd != fd --- and in the case where blocks are encrypted using
> fscrypt, we will have to decrypt the blocks from donor_fd and possibly
> re-encrypt then in fd's per-file key, which means we'll have to add
> extra complexity to implement the decrypt and re-encrypt passing
> through the page cache.
>
> But if this helps resolve Christoph and Dave's objections, it
> shouldn't be _too_ much extra complexity. Before we go ahead an
> implement it, though, I'd appreciate a confirmation that this will
> indeed actually resolve their complaints.
>
> Thanks,
>
> - Ted
next prev parent reply other threads:[~2019-01-10 18:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 5:15 Proposal: A new fs-verity interface Theodore Y. Ts'o
2019-01-10 5:15 ` Theodore Y. Ts'o
2019-01-10 18:18 ` Darrick J. Wong [this message]
2019-01-10 18:18 ` Darrick J. Wong
2019-01-14 23:41 ` Dave Chinner
2019-01-14 23:41 ` Dave Chinner
2019-01-23 5:10 ` Theodore Y. Ts'o
2019-01-24 21:25 ` Dave Chinner
2019-01-24 21:40 ` Linus Torvalds
2019-01-24 23:22 ` Theodore Y. Ts'o
2019-01-25 0:32 ` Matthew Wilcox
2019-01-25 0:35 ` Linus Torvalds
2019-01-29 15:48 ` 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=20190110181836.GA20467@magnolia \
--to=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).