From: Eric Biggers <ebiggers@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-integrity@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
"Theodore Y . Ts'o" <tytso@mit.edu>,
Victor Hsieh <victorhsieh@google.com>,
Dave Chinner <david@fromorbit.com>,
Christoph Hellwig <hch@lst.de>,
"Darrick J . Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH v4 00/16] fs-verity: read-only file-based authenticity protection
Date: Thu, 6 Jun 2019 12:43:44 -0700 [thread overview]
Message-ID: <20190606194343.GA84833@gmail.com> (raw)
In-Reply-To: <CAHk-=wgSzRzoro8ATO5xb6OFxN1A0fjUCQSAHfGuEPbEu+zWvA@mail.gmail.com>
On Thu, Jun 06, 2019 at 10:21:12AM -0700, Linus Torvalds wrote:
> On Thu, Jun 6, 2019 at 8:54 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > This is a redesigned version of the fs-verity patchset, implementing
> > Ted's suggestion to build the Merkle tree in the kernel
> > (https://lore.kernel.org/linux-fsdevel/20190207031101.GA7387@mit.edu/).
> > This greatly simplifies the UAPI, since the verity metadata no longer
> > needs to be transferred to the kernel.
>
> Interfaces look sane to me. My only real concern is whether it would
> make sense to make the FS_IOC_ENABLE_VERITY ioctl be something that
> could be done incrementally, since the way it is done now it looks
> like any random user could create a big file and then do the
> FS_IOC_ENABLE_VERITY to make the kernel do a _very_ expensive
> operation.
>
> Yes, I see the
>
> + if (fatal_signal_pending(current))
> + return -EINTR;
> + cond_resched();
>
> in there, so it's not like it's some entirely unkillable thing, and
> maybe we don't care as a result. But maybe the ioctl interface could
> be fundamentally restartable?
>
> If that was already considered and people just went "too complex", never mind.
>
> Linus
Making it incremental would be complex. We could make FS_IOC_ENABLE_VERITY
write checkpoints periodically, and make it resume from the checkpoint if
present. But then we'd have to worry about sync'ing the Merkle tree before
writing each checkpoint, and storing the Merkle tree parameters in each
checkpoint so that if the second call to FS_IOC_ENABLE_VERITY is made with
different parameters it knows to delete everything and restart from scratch.
Or we could make it explicit in the UAPI, where userspace calls ioctls to build
blocks 0 through 9999, then 10000 through 19999, etc. But that would make the
UAPI much more complex, and the kernel would need to do lots of extra validation
of the parameters passed in. This approach would also not be crash-safe unless
userspace did its own checkpointing, whereas the all-or-nothing API naturally
avoids inconsistent states.
And either way of making it incremental, the "partial Merkle tree" would also
become a valid on-disk state. Conceptually that adds a lot of complexity, and
probably people would want fsck to support removing all the partial trees,
similar to how e2fsck supports optimizing directories and extent trees.
So in the end, it's not something I decided to add.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Linux API <linux-api@vger.kernel.org>,
Dave Chinner <david@fromorbit.com>,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-integrity@vger.kernel.org, linux-ext4@vger.kernel.org,
Christoph Hellwig <hch@lst.de>,
Victor Hsieh <victorhsieh@google.com>
Subject: Re: [PATCH v4 00/16] fs-verity: read-only file-based authenticity protection
Date: Thu, 6 Jun 2019 12:43:44 -0700 [thread overview]
Message-ID: <20190606194343.GA84833@gmail.com> (raw)
In-Reply-To: <CAHk-=wgSzRzoro8ATO5xb6OFxN1A0fjUCQSAHfGuEPbEu+zWvA@mail.gmail.com>
On Thu, Jun 06, 2019 at 10:21:12AM -0700, Linus Torvalds wrote:
> On Thu, Jun 6, 2019 at 8:54 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > This is a redesigned version of the fs-verity patchset, implementing
> > Ted's suggestion to build the Merkle tree in the kernel
> > (https://lore.kernel.org/linux-fsdevel/20190207031101.GA7387@mit.edu/).
> > This greatly simplifies the UAPI, since the verity metadata no longer
> > needs to be transferred to the kernel.
>
> Interfaces look sane to me. My only real concern is whether it would
> make sense to make the FS_IOC_ENABLE_VERITY ioctl be something that
> could be done incrementally, since the way it is done now it looks
> like any random user could create a big file and then do the
> FS_IOC_ENABLE_VERITY to make the kernel do a _very_ expensive
> operation.
>
> Yes, I see the
>
> + if (fatal_signal_pending(current))
> + return -EINTR;
> + cond_resched();
>
> in there, so it's not like it's some entirely unkillable thing, and
> maybe we don't care as a result. But maybe the ioctl interface could
> be fundamentally restartable?
>
> If that was already considered and people just went "too complex", never mind.
>
> Linus
Making it incremental would be complex. We could make FS_IOC_ENABLE_VERITY
write checkpoints periodically, and make it resume from the checkpoint if
present. But then we'd have to worry about sync'ing the Merkle tree before
writing each checkpoint, and storing the Merkle tree parameters in each
checkpoint so that if the second call to FS_IOC_ENABLE_VERITY is made with
different parameters it knows to delete everything and restart from scratch.
Or we could make it explicit in the UAPI, where userspace calls ioctls to build
blocks 0 through 9999, then 10000 through 19999, etc. But that would make the
UAPI much more complex, and the kernel would need to do lots of extra validation
of the parameters passed in. This approach would also not be crash-safe unless
userspace did its own checkpointing, whereas the all-or-nothing API naturally
avoids inconsistent states.
And either way of making it incremental, the "partial Merkle tree" would also
become a valid on-disk state. Conceptually that adds a lot of complexity, and
probably people would want fsck to support removing all the partial trees,
similar to how e2fsck supports optimizing directories and extent trees.
So in the end, it's not something I decided to add.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Linux API <linux-api@vger.kernel.org>,
Dave Chinner <david@fromorbit.com>,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-integrity@vger.kernel.org, linux-ext4@vger.kernel.org,
Christoph Hellwig <hch@lst.de>,
Victor Hsieh <victorhsieh@google.com>
Subject: Re: [f2fs-dev] [PATCH v4 00/16] fs-verity: read-only file-based authenticity protection
Date: Thu, 6 Jun 2019 12:43:44 -0700 [thread overview]
Message-ID: <20190606194343.GA84833@gmail.com> (raw)
Message-ID: <20190606194344.mrxEy1-3Msy3YUUE-OwAHa9ofeB0fwn3gF7Wrwbl3uc@z> (raw)
In-Reply-To: <CAHk-=wgSzRzoro8ATO5xb6OFxN1A0fjUCQSAHfGuEPbEu+zWvA@mail.gmail.com>
On Thu, Jun 06, 2019 at 10:21:12AM -0700, Linus Torvalds wrote:
> On Thu, Jun 6, 2019 at 8:54 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > This is a redesigned version of the fs-verity patchset, implementing
> > Ted's suggestion to build the Merkle tree in the kernel
> > (https://lore.kernel.org/linux-fsdevel/20190207031101.GA7387@mit.edu/).
> > This greatly simplifies the UAPI, since the verity metadata no longer
> > needs to be transferred to the kernel.
>
> Interfaces look sane to me. My only real concern is whether it would
> make sense to make the FS_IOC_ENABLE_VERITY ioctl be something that
> could be done incrementally, since the way it is done now it looks
> like any random user could create a big file and then do the
> FS_IOC_ENABLE_VERITY to make the kernel do a _very_ expensive
> operation.
>
> Yes, I see the
>
> + if (fatal_signal_pending(current))
> + return -EINTR;
> + cond_resched();
>
> in there, so it's not like it's some entirely unkillable thing, and
> maybe we don't care as a result. But maybe the ioctl interface could
> be fundamentally restartable?
>
> If that was already considered and people just went "too complex", never mind.
>
> Linus
Making it incremental would be complex. We could make FS_IOC_ENABLE_VERITY
write checkpoints periodically, and make it resume from the checkpoint if
present. But then we'd have to worry about sync'ing the Merkle tree before
writing each checkpoint, and storing the Merkle tree parameters in each
checkpoint so that if the second call to FS_IOC_ENABLE_VERITY is made with
different parameters it knows to delete everything and restart from scratch.
Or we could make it explicit in the UAPI, where userspace calls ioctls to build
blocks 0 through 9999, then 10000 through 19999, etc. But that would make the
UAPI much more complex, and the kernel would need to do lots of extra validation
of the parameters passed in. This approach would also not be crash-safe unless
userspace did its own checkpointing, whereas the all-or-nothing API naturally
avoids inconsistent states.
And either way of making it incremental, the "partial Merkle tree" would also
become a valid on-disk state. Conceptually that adds a lot of complexity, and
probably people would want fsck to support removing all the partial trees,
similar to how e2fsck supports optimizing directories and extent trees.
So in the end, it's not something I decided to add.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-06-06 19:43 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 15:51 [PATCH v4 00/16] fs-verity: read-only file-based authenticity protection Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-06 15:51 ` [PATCH v4 01/16] fs-verity: add a documentation file Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 12:39 ` Theodore Ts'o
2019-06-15 12:39 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 12:39 ` Theodore Ts'o
2019-06-18 16:31 ` Eric Biggers
2019-06-18 16:31 ` [f2fs-dev] " Eric Biggers
2019-06-18 16:31 ` Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] [PATCH v4 02/16] fs-verity: add MAINTAINERS file entry Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 12:39 ` Theodore Ts'o
2019-06-15 12:39 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 12:39 ` Theodore Ts'o
2019-06-06 15:51 ` [f2fs-dev] [PATCH v4 03/16] fs-verity: add UAPI header Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] [PATCH v4 04/16] fs: uapi: define verity bit for FS_IOC_GETFLAGS Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 12:40 ` Theodore Ts'o
2019-06-15 12:40 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 12:40 ` Theodore Ts'o
2019-06-06 15:51 ` [PATCH v4 05/16] fs-verity: add Kconfig and the helper functions for hashing Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 12:57 ` Theodore Ts'o
2019-06-15 12:57 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 12:57 ` Theodore Ts'o
2019-06-18 16:32 ` Eric Biggers
2019-06-18 16:32 ` [f2fs-dev] " Eric Biggers
2019-06-18 16:32 ` Eric Biggers
2019-06-06 15:51 ` [PATCH v4 06/16] fs-verity: add inode and superblock fields Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 12:57 ` Theodore Ts'o
2019-06-15 12:57 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 12:57 ` Theodore Ts'o
2019-06-06 15:51 ` [PATCH v4 07/16] fs-verity: add the hook for file ->open() Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 14:42 ` Theodore Ts'o
2019-06-15 14:42 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 14:42 ` Theodore Ts'o
2019-06-18 16:35 ` Eric Biggers
2019-06-18 16:35 ` [f2fs-dev] " Eric Biggers
2019-06-18 16:35 ` Eric Biggers
2019-06-06 15:51 ` [PATCH v4 08/16] fs-verity: add the hook for file ->setattr() Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 14:43 ` Theodore Ts'o
2019-06-15 14:43 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 14:43 ` Theodore Ts'o
2019-06-06 15:51 ` [PATCH v4 09/16] fs-verity: add data verification hooks for ->readpages() Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 14:48 ` Theodore Ts'o
2019-06-15 14:48 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 14:48 ` Theodore Ts'o
2019-06-06 15:51 ` [PATCH v4 10/16] fs-verity: implement FS_IOC_ENABLE_VERITY ioctl Eric Biggers
2019-06-06 15:51 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:51 ` Eric Biggers
2019-06-15 15:08 ` Theodore Ts'o
2019-06-15 15:08 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 15:08 ` Theodore Ts'o
2019-06-18 16:50 ` Eric Biggers
2019-06-18 16:50 ` [f2fs-dev] " Eric Biggers
2019-06-18 16:50 ` Eric Biggers
2019-06-06 15:52 ` [PATCH v4 11/16] fs-verity: implement FS_IOC_MEASURE_VERITY ioctl Eric Biggers
2019-06-06 15:52 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:52 ` Eric Biggers
2019-06-15 15:10 ` Theodore Ts'o
2019-06-15 15:10 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 15:10 ` Theodore Ts'o
2019-06-06 15:52 ` [PATCH v4 12/16] fs-verity: add SHA-512 support Eric Biggers
2019-06-06 15:52 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:52 ` Eric Biggers
2019-06-15 15:11 ` Theodore Ts'o
2019-06-15 15:11 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 15:11 ` Theodore Ts'o
2019-06-06 15:52 ` [PATCH v4 13/16] fs-verity: support builtin file signatures Eric Biggers
2019-06-06 15:52 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:52 ` Eric Biggers
2019-06-15 15:21 ` Theodore Ts'o
2019-06-15 15:21 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 15:21 ` Theodore Ts'o
2019-06-18 16:58 ` Eric Biggers
2019-06-18 16:58 ` [f2fs-dev] " Eric Biggers
2019-06-18 16:58 ` Eric Biggers
2019-06-06 15:52 ` [PATCH v4 14/16] ext4: add basic fs-verity support Eric Biggers
2019-06-06 15:52 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:52 ` Eric Biggers
2019-06-15 15:31 ` Theodore Ts'o
2019-06-15 15:31 ` [f2fs-dev] " Theodore Ts'o
2019-06-15 15:31 ` Theodore Ts'o
2019-06-18 17:51 ` Eric Biggers
2019-06-18 17:51 ` [f2fs-dev] " Eric Biggers
2019-06-18 17:51 ` Eric Biggers
2019-06-18 22:46 ` Theodore Ts'o
2019-06-18 22:46 ` [f2fs-dev] " Theodore Ts'o
2019-06-18 22:46 ` Theodore Ts'o
2019-06-18 23:41 ` Eric Biggers
2019-06-18 23:41 ` [f2fs-dev] " Eric Biggers
2019-06-18 23:41 ` Eric Biggers
2019-06-19 3:05 ` Theodore Ts'o
2019-06-19 3:05 ` [f2fs-dev] " Theodore Ts'o
2019-06-19 3:05 ` Theodore Ts'o
2019-06-19 19:13 ` Eric Biggers
2019-06-19 19:13 ` [f2fs-dev] " Eric Biggers
2019-06-19 19:13 ` Eric Biggers
2019-06-06 15:52 ` [PATCH v4 15/16] ext4: add fs-verity read support Eric Biggers
2019-06-06 15:52 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:52 ` Eric Biggers
2019-06-06 15:52 ` [PATCH v4 16/16] f2fs: add fs-verity support Eric Biggers
2019-06-06 15:52 ` [f2fs-dev] " Eric Biggers
2019-06-06 15:52 ` Eric Biggers
2019-06-06 17:21 ` [PATCH v4 00/16] fs-verity: read-only file-based authenticity protection Linus Torvalds
2019-06-06 17:21 ` [f2fs-dev] " Linus Torvalds
2019-06-06 17:21 ` Linus Torvalds
2019-06-06 19:43 ` Eric Biggers [this message]
2019-06-06 19:43 ` [f2fs-dev] " Eric Biggers
2019-06-06 19:43 ` 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=20190606194343.GA84833@gmail.com \
--to=ebiggers@kernel.org \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jaegeuk@kernel.org \
--cc=linux-api@vger.kernel.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=linux-integrity@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=victorhsieh@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.