Re: IMA: Avoid redundant rehashing on stacked filesystems backed by structurally immutable filesystems

Mimi Zohar <[email protected]>
Newsgroups org.kernel.vger.linux-integrity
Message-ID <[email protected]>
On Thu, 2026-04-30 at 16:55 -0700, Danny Hu wrote:
> Hi,
> 
> We observed that IMA will always invalidate the cached measurement
> result and re-hash a file on overlayfs stacked on top of squashfs. The
> behavior was introduced by commit b836c4d29f27 ("ima: detect changes
> to the backing overlay file”). We would like some feedback on the
> proposed direction we are considering before sending in any patches.
> 
> Problem:
> 
> process_measurement() in security/integrity/ima/ima_main.c includes a
> stacked-filesystem re-evaluation block that clears IMA_DONE_MASK when
> the backing inode is not IS_I_VERSION. This check does not
> differentiate between two distinct cases:
> 
> 1. The backing fs does not implement i_version but it's inodes can change
> 2. The backing fs does not need  i_version because it's inodes cannot change
> 
> For the latter case, squashfs being an inherently immutable filesystem
> with no write paths does not set the IS_I_VERSION flag and ends up
> paying the cost of IMA hashing on every single IMA appraisal
> operation. This is perhaps overly conservative because the contents of
> squashfs cannot be modified anyways so the cached result will never be
> stale.
> 
> 
> Proposed direction:
> 
> Add an s_iflags bit, potentially SB_I_IMMUTABLE, that a filesystem can
> set in fill_super to indicate that it is structurally immutable. IMA
> can then leverage this bit to short circuit the stacked-fs
> re-evaluation block and trust the cached appraisal value instead of
> forcing a re-hash. A motivator for this approach is to follow existing
> precedent. IMA already consults s_iflags for filesystem facts that
> affect appraisal. The SB_I_IMA_UNVERIFIABLE_SIGNATURE flag is already
> checked in the same process_measurement() in the block above the
> stacked fs re-evaluation.
> 
> Happy to provide more details or clarifications if required.

Have you considered using IS_RDONLY(real_inode)?

Mimi
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.