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
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
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
> 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
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
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
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
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
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
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
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
11 matches
Mail list logo