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

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

[Danny Hu]

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.

Thanks,
Danny

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

[Mimi Zohar]

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

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

[Sahil Gupta]

> Have you considered using IS_RDONLY(real_inode)?

OOC are ima caches invalidated on fs reconfigure? If that is the case,
then IS_RDONLY ought to do the trick.

Sahil

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

[Mimi Zohar]

On Thu, 2026-04-30 at 21:32 -0500, Sahil Gupta wrote:
> > Have you considered using IS_RDONLY(real_inode)?
> 
> OOC are ima caches invalidated on fs reconfigure? If that is the case,
> then IS_RDONLY ought to do the trick.

Per-inode IMA integrity status (iint) is now stored directly in the inode's LSM
security blob rather than in a red-black tree cache.  By "fs reconfiguration",
do you mean remounting the filesystem?  If so, the iint stored in the LSM
security blob should be freed when the filesystem is unmounted.

Mimi

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

[Sahil Gupta]

> By "fs reconfiguration", do you mean remounting the filesystem? If so, the iint stored in the LSM security blob should be freed when the filesystem is unmounted.

I'm a visitor to VFS code, but from what I surmise, a remount doesn't
seem to be equivalent to an unmount + a subsequent mount. It's clear
to me that an explicit unmount would eventually call evict_inodes() ->
... -> security_inode_free(), but I don't trace such a path when
remounting it.

Sahil

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

[Danny Hu]

On Fri, May 1, 2026 at 4:42 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Thu, 2026-04-30 at 21:32 -0500, Sahil Gupta wrote:
> > > Have you considered using IS_RDONLY(real_inode)?
> >
> > OOC are ima caches invalidated on fs reconfigure? If that is the case,
> > then IS_RDONLY ought to do the trick.
>
> Per-inode IMA integrity status (iint) is now stored directly in the inode's LSM
> security blob rather than in a red-black tree cache.  By "fs reconfiguration",
> do you mean remounting the filesystem?  If so, the iint stored in the LSM
> security blob should be freed when the filesystem is unmounted.
>

We considered using IS_RDONLY(), but the concern involved the remount
path rather than an explicit unmount and subsequent mount. From my
understanding, userspace can toggle the read only flag using "mount -o
remount,rw" without freeing the inodes from memory. A malicious user
could then exploit this by caching the appraisal result, modifying the
file, remounting fs as read-only, and then IMA would trust the cached
appraisal result.

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

[Mimi Zohar]

On Fri, 2026-05-01 at 09:16 -0700, Danny Hu wrote:
> On Fri, May 1, 2026 at 4:42 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Thu, 2026-04-30 at 21:32 -0500, Sahil Gupta wrote:
> > > > Have you considered using IS_RDONLY(real_inode)?
> > > 
> > > OOC are ima caches invalidated on fs reconfigure? If that is the case,
> > > then IS_RDONLY ought to do the trick.
> > 
> > Per-inode IMA integrity status (iint) is now stored directly in the inode's LSM
> > security blob rather than in a red-black tree cache.  By "fs reconfiguration",
> > do you mean remounting the filesystem?  If so, the iint stored in the LSM
> > security blob should be freed when the filesystem is unmounted.
> > 
> 
> We considered using IS_RDONLY(), but the concern involved the remount
> path rather than an explicit unmount and subsequent mount. From my
> understanding, userspace can toggle the read only flag using "mount -o
> remount,rw" without freeing the inodes from memory. A malicious user
> could then exploit this by caching the appraisal result, modifying the
> file, remounting fs as read-only, and then IMA would trust the cached
> appraisal result.

Thank you for the explanation. Just be aware that IS_IMMUTABLE  is already
defined.  Otherwise your suggestion is plausible.

Mimi

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

[Sahil Gupta]

I don't think inode immutability would be helpful here either because
you can mark an inode as immutable after you've written to it.

Sahil

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

[Danny Hu]

On Fri, May 1, 2026 at 12:48 PM Mimi Zohar <zohar@linux.ibm.com> wrote:

> Thank you for the explanation. Just be aware that IS_IMMUTABLE  is already
> defined.  Otherwise your suggestion is plausible.

Thanks for your input! We will likely pursue this approach internally
and send some patches upstream once more testing is complete.