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
