On Wed, Oct 10, 2018 at 4:09 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > On Tue, 2018-10-09 at 14:32 -0700, Matthew Garrett wrote: > > 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? The trust /has/ to be bi-directional - if FUSE isn't trustworthy then it can return false data after the measurement, since we're not performing measurements at every read. FUSE can recalculate the hash once a write occurs (it has all the rest of the data already), whereas having the kernel redo it requires it to read the entire data back from FUSE. This patch still leaves FUSE measurements as uncached, so the filesystem will be queried for a new hash every time we want a new measurement. For cases where there's no benefit in having the filesystem do the hashing, the filesystem can simply not provide the feature and the kernel will continue using the existing code.
