linux-kernel - Re: [PATCH RFC] ima: Fallback to a ctime guard without i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4a4778ff395e533cad86ff3ffbf0ba90c3eb8798.camel@linux.ibm.com>
Date: Mon, 05 Jan 2026 17:15:15 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Frederick Lawler <fred@...udflare.com>,
        Roberto Sassu	
 <roberto.sassu@...wei.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        Eric Snowberg <eric.snowberg@...cle.com>,
        Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn"	 <serge@...lyn.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Christian Brauner	
 <brauner@...nel.org>,
        Josef Bacik <josef@...icpanda.com>, Jeff Layton	
 <jlayton@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: [PATCH RFC] ima: Fallback to a ctime guard without i_version
 updates

On Mon, 2025-12-29 at 11:52 -0600, Frederick Lawler wrote:
> Since commit 1cf7e834a6fb ("xfs: switch to multigrain timestamps"), IMA
> is no longer able to correctly track inode.i_version due to the struct
> kstat.change_cookie no longer containing an updated i_version.
> 
> Introduce a fallback mechanism for IMA that instead tracks a
> integrity_ctime_guard() in absence of or outdated i_version
> for stacked file systems.

Thanks, Frederick.

Instead of using the new function name integrity_ctime_guard() to describe the
change, please describe the change in words.  Perhaps something like: rely on
the inode's ctime to detect a file data or metadata change.

The purpose of generating a ctime guard value, as opposed to using the tv_sec
and tv_nsec, I assume is to minimize the amount of memory being saved in the
iint.

> 
> EVM is left alone since it mostly cares about the backing inode.
> 
> Link: https://lore.kernel.org/all/aTspr4_h9IU4EyrR@CMGLRV3
> Fixes: 1cf7e834a6fb ("xfs: switch to multigrain timestamps")
> Suggested-by: Jeff Layton <jlayton@...nel.org>
> Signed-off-by: Frederick Lawler <fred@...udflare.com>
> ---
> The motivation behind this was that file systems that use the
> cookie to set the i_version for stacked file systems may still do so.
> Then add in the ctime_guard as a fallback if there's a detected change.
> The assumption is that the ctime will be different if the i_version is
> different anyway for non-stacked file systems.

Agreed. This patch inverts the i_version test to return immediately if the
i_version hasn't changed and then checks the ctime guard value.  Is the ctime
guard value test simply a performance improvement?

> 
> I'm not too pleased with passing in struct file* to
> integrity_inode_attrs_changed() since EVM doesn't currently use
> that for now, but I couldn't come up with another idea to get the
> stat without coming up with a new stat function to accommodate just
> the file path, fully separate out IMA/EVM checks, or lastly add stacked
> file system support to EVM (which doesn't make much sense to me
> at the moment).
> 
> I plan on adding in self test infrastructure for the v1, but I would
> like to get some early feedback on the approach first.

I really appreciate your adding a self test.

thanks,

Mimi