From: "Darrick J. Wong" <darrick.wong@oracle.com> To: "Theodore Y. Ts'o" <tytso@mit.edu> Cc: Eric Biggers <ebiggers@kernel.org>, Dave Chinner <david@fromorbit.com>, linux-f2fs-devel@lists.sourceforge.net, Christoph Hellwig <hch@infradead.org>, linux-fscrypt@vger.kernel.org, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-ext4@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org> 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) 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
WARNING: multiple messages have this Message-ID (diff)
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:18 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: linkBe 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).