On Tue, 2018-10-09 at 14:32 -0700, Matthew Garrett wrote: > On Tue, Oct 9, 2018 at 1:52 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > > The performance hit is more noticeable over remote filesystems, but we > > > have large binaries that take several seconds to hash even on local > > > filesystems. Would it be helpful to try to define the assumptions that > > > IMA makes in terms of whether or not it produces trustworthy results? > > > It feels like it's be easier to talk about this if we have a more > > > formal set of conditions to take into consideration. > > > > [Cc'ing Chuck Lever] > > > > Integrity of files on remote filesystems should probably be discussed > > in the context of fs-verity, not FUSE filesystems. > > Hm. We /could/ fake up fs-verity style behaviour, but we're not > talking about files that are expected to be immutable so it would seem > like there might be mismatched semantics there. If these aren't immutable files, then the file hash needs to be calculated and re-calculated on file change. Trust between the kernel and FUSE isn't bi-directional. IMA already supports hardware crypto acceleration. (Refer to the "ima.ahash_minsize" and "ima.ahash_bufsize" boot command line options.) Why is it better that FUSE calculates the file hash than the kernel? Mimi
