From: Frederick Lawler <fred@cloudflare.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Roberto Sassu <roberto.sassu@huaweicloud.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Eric Snowberg <eric.snowberg@oracle.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Christian Brauner <brauner@kernel.org>,
Josef Bacik <josef@toxicpanda.com>,
Jeff Layton <jlayton@kernel.org>,
linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
kernel-team@cloudflare.com
Subject: Re: [PATCH v5 3/3] ima: Use kstat.ctime as a fallback change detection for stacked fs
Date: Fri, 6 Feb 2026 14:06:57 -0600 [thread overview]
Message-ID: <aYZJ4Y33oRRk5Drs@CMGLRV3> (raw)
In-Reply-To: <6f82d5dc6b499ecd03c985d6de20de94fea04cfe.camel@linux.ibm.com>
On Wed, Feb 04, 2026 at 11:26:27PM -0500, Mimi Zohar wrote:
> On Wed, 2026-02-04 at 15:22 -0600, Frederick Lawler wrote:
> > That said, I think Mimi pointed out in an email [2] where multi-grain
> > file systems are impacted regardless of stacked fs or not due to the last
> > writer check.
> >
> > I don't recall coming across that in my tests, but perhaps I did that
> > specific test wrong? To be sure, I created the C program, and on the VM,
> > created a XFS disk, mounted it on loopback, ran the rdwr program on
> > "somefile" multiple times, and only got 1 audit log for it, until I
> > mutated it with touch, and only got 2 hits: original + after mutation
> > after running the program multiple times.
> >
> > I'm not sure what's going on there, so I'll look into that a bit more,
> > but so far the impact is stacked file systems & multigrain ctime AFAIK.
>
> Make sure you're testing without your patch set applied or at least the last
> patch.
>
I'm still not sure what went wrong with my test suite, but spinning up a
VM similar to Mimi's, I was able to reproduce the last writer issue. I
used patch 1 as a baseline because that's noop from base 6.19, and used
that function as a convenient trace point.
And, then running the attached example test for stacked FS works as
expected on both patches 1 (multiple log messages) & 3 (just one log
message).
I left out the dump_stack() in integrity_inode_attrs_stat_change()
for readability in these results. For Mimi's test, we just see
calls into ima_check_last_writer(), and for the attached sample
in 0/0, we get the calls straight from process_measurement() for
stacked fs. Running Mimi's and then attached in that order, I get
double the logs because the FILE_CHECK is hitting the last writer,
and we get the process_measurement() for the binary run.
Based on all of this, I can drop the stacked FS wording in the patch
descriptions, and keep it all focused that the change_cookie semantics
have been changed for multigrain file systems.
Results:
PATCH 1/3
[root@localhost ~]# ./mimi.sh
filename: /usr/bin/date-20260206140427
filename: /usr/bin/date-20260206140427
filename: /usr/bin/date-20260206140427
FAIL: Expected 1 audit event, but found 3.
[ 26.033572] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=0 change_cookie=0
[ 26.034372] ima: fred: ima_check_last_writer: must measure file: "/usr/bin/date-20260206140427"
[ 26.037453] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=0 change_cookie=0
[ 26.038425] ima: fred: ima_check_last_writer: must measure file: "/usr/bin/date-20260206140427"
[ 26.039821] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=0 change_cookie=0
[ 26.041383] ima: fred: ima_check_last_writer: must measure file: "/usr/bin/date-20260206140427"
[root@localhost fred-tests]# ./simple-fedora.sh
314572800 bytes (315 MB, 300 MiB) copied, 0.132908 s, 2.4 GB/s
Fri Feb 6 14:56:18 EST 2026
Fri Feb 6 14:56:18 EST 2026
Fri Feb 6 14:56:18 EST 2026
Fri Feb 6 14:56:18 EST 2026
FAIL: Expected 1 audit event, but found 4.
Note: Does not have dmesg output because this patch didn't put the trace
function into integrity_inode_attrs_changed().
PATCH 3/3
[root@localhost ~]# ./mimi.sh
filename: /usr/bin/date-20260206140141
filename: /usr/bin/date-20260206140141
filename: /usr/bin/date-20260206140141
PASS: Found exactly 1 audit event.
[ 17.191235] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770404501462431821 change_cookie=0
[ 17.192213] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770404501462431821 ctime=1770404501462431821
[ 17.196325] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770404501462431821 change_cookie=0
[ 17.197380] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770404501462431821 ctime=1770404501462431821
[ 17.199750] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770404501462431821 change_cookie=0
[ 17.200682] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770404501462431821 ctime=1770404501462431821
[root@localhost fred-tests]# ./simple-fedora.sh
Fri Feb 6 14:53:30 EST 2026
Fri Feb 6 14:53:30 EST 2026
Fri Feb 6 14:53:30 EST 2026
Fri Feb 6 14:53:30 EST 2026
PASS: Found exactly 1 audit event.
[ 23.315358] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770407920086616962 change_cookie=0
[ 23.328978] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770407920086616962 ctime=1770407920086616962
[ 23.332122] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770407920086616962 change_cookie=0
[ 23.347162] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770407920086616962 ctime=1770407920086616962
[ 23.352931] fred: integrity_inode_attrs_stat_changed result_mask=0 (change cookie) version=1770407920086616962 change_cookie=0
[ 23.368026] fred: integrity_inode_attrs_stat_changed result_mask=128 (ctime) version=1770407920086616962 ctime=1770407920086616962
Note that the in stacked FS case, process_measurement() skipped the check
for attrs changed, and skipped to measuring. Subsequent calls into
process_measurement() hits the integrity_inode_attrs_stat_changed().
prev parent reply other threads:[~2026-02-06 20:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 22:39 [PATCH v5 0/3] ima: Detect changes to files via kstat changes rather than i_version Frederick Lawler
2026-01-30 22:39 ` [PATCH v5 1/3] ima: Unify vfs_getattr_nosec() stat comparisons under helper function Frederick Lawler
2026-01-30 22:39 ` [PATCH v5 2/3] ima: Make integrity_inode_attrs_changed() call into vfs Frederick Lawler
2026-02-04 12:34 ` Roberto Sassu
2026-02-04 19:35 ` Frederick Lawler
2026-01-30 22:39 ` [PATCH v5 3/3] ima: Use kstat.ctime as a fallback change detection for stacked fs Frederick Lawler
2026-02-04 12:36 ` Roberto Sassu
2026-02-04 21:22 ` Frederick Lawler
2026-02-05 4:26 ` Mimi Zohar
2026-02-06 20:06 ` Frederick Lawler [this message]
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=aYZJ4Y33oRRk5Drs@CMGLRV3 \
--to=fred@cloudflare.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=jlayton@kernel.org \
--cc=jmorris@namei.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=roberto.sassu@huaweicloud.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.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