Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-12 Thread Eric Biggers
On Tue, Feb 12, 2019 at 12:24:33PM -0500, Theodore Y. Ts'o wrote: > > > > > The existing file hashes included in the measurement list and the > > > > audit log, are currently being used for remote attestation, forensics > > > > and security analytics. > > > > Again, the context for this comment

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-12 Thread Theodore Y. Ts'o
On Tue, Feb 12, 2019 at 08:06:52AM -0500, Mimi Zohar wrote: > Yes, I understand that your primary goal hasn't changed.  Linus was > suggesting "the interface be made idempotent" to support "filesystems > that don't actually have any long-term storage model for the merkle > tree.  IOW, you could do

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-12 Thread Theodore Y. Ts'o
On Tue, Feb 12, 2019 at 09:44:39AM -0500, Mimi Zohar wrote: > Ted, one of the problems with IMA is that the file hash/signature > verification is at file open.  It isn't aware when files are brought > in from cache.  Does fs-verity re-verify blocks as they're restored > from cache?  For some use

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-12 Thread Mimi Zohar
> At that point, the merkle tree thing ends up fairly equivalent to the > > IMA "measurement" thing, with the exception that the filesystem *may* > > optimize it to be long-term. Hmm? > > Well, except that it's just a less efficient way of doing IMA > "measurement" (if the file system doesn't

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-12 Thread Mimi Zohar
Hi Ted, The context for my comments/questions was Linus' suggestions, which you've removed. On Tue, 2019-02-12 at 00:31 -0500, Theodore Y. Ts'o wrote: > On Sun, Feb 10, 2019 at 09:06:55AM -0500, Mimi Zohar wrote: > > For which files will the Merkle tree be created? Is this for all > > files on

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-12 Thread Theodore Y. Ts'o
On Sun, Feb 10, 2019 at 09:06:55AM -0500, Mimi Zohar wrote: > For which files will the Merkle tree be created? Is this for all > files on a per file system basis?  Or is there some sort of "flag" or > policy? The original design was based on an ioctl enabling/disabling > a flag. In this new

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-11 Thread Theodore Y. Ts'o
On Sat, Feb 09, 2019 at 12:38:05PM -0800, Linus Torvalds wrote: > > In particular, may I suggest that the interface be made idempotent, > so that you can do the merkle tree operation several times with the > same offset/length arguments, and if the merkle tree has already been > calculated, you

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-10 Thread Mimi Zohar
On Sat, 2019-02-09 at 12:38 -0800, Linus Torvalds wrote: > On Thu, Feb 7, 2019 at 8:10 AM Theodore Y. Ts'o wrote: > > > > 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

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-09 Thread Linus Torvalds
On Thu, Feb 7, 2019 at 8:10 AM Theodore Y. Ts'o wrote: > > 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

Re: [f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-08 Thread James Bottomley
On Wed, 2019-02-06 at 22:11 -0500, Theodore Y. Ts'o wrote: > 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

[f2fs-dev] Proposal: Yet another possible fs-verity interface

2019-02-07 Thread Theodore Y. Ts'o
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