Linux Integrity Measurement development
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Danny Hu <dannyhu@arista.com>, linux-integrity@vger.kernel.org
Cc: Sahil Gupta <s.gupta@arista.com>,
	Julien Gomes <julien@arista.com>,
	Pierre De Abreu <pierre@arista.com>,
	Kunal Bharathi <kbharathi@arista.com>
Subject: Re: IMA: Avoid redundant rehashing on stacked filesystems backed by structurally immutable filesystems
Date: Thu, 30 Apr 2026 22:29:54 -0400	[thread overview]
Message-ID: <2b3c93a69e70b6fdf637bf9fb921d5e737a79e8e.camel@linux.ibm.com> (raw)
In-Reply-To: <CAFn2k5DJNv5SDsx_-odHd3sB0Fw7r8FqhO8fWdXrraZn_vbpDw@mail.gmail.com>

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

  reply	other threads:[~2026-05-01  2:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 23:55 IMA: Avoid redundant rehashing on stacked filesystems backed by structurally immutable filesystems Danny Hu
2026-05-01  2:29 ` Mimi Zohar [this message]
2026-05-01  2:32   ` Sahil Gupta
2026-05-01 11:42     ` Mimi Zohar
2026-05-01 16:02       ` Sahil Gupta
2026-05-01 16:16       ` Danny Hu
2026-05-01 19:48         ` Mimi Zohar
2026-05-01 20:05           ` Sahil Gupta
2026-05-01 20:22           ` Danny Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b3c93a69e70b6fdf637bf9fb921d5e737a79e8e.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=dannyhu@arista.com \
    --cc=julien@arista.com \
    --cc=kbharathi@arista.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=pierre@arista.com \
    --cc=s.gupta@arista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox