From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3004C2D3ECF for ; Mon, 5 Jan 2026 23:09:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767654596; cv=none; b=QsrJuElcLd/959XX6BeRIbWgXjgMWqzA9by2hcPkl4bnTX2+eTSxo7OyzKrCry9aiwPM/gPq7xjYw1cfOTgQAncW4dJnEXuMHkovweOk/tj4ZBqGmm7OLD7guerAOs7fRv3BoFiBIW93VzTUnka2AiDXxfW8F+z1XxbGKVZCbNA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767654596; c=relaxed/simple; bh=avo5CR9Z1DYQeJXwYN+xxzxXqUvd/jN3tXFeP6w6pys=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MQdXsoGxE0h5DA8uVDvD67/EjvUKJWZo3DFMQwIxKRwH6GzOSoH/w1L2XaDkOoYOZ1+NrlbVVTgLw5qCV5NsAW1dhDP/H83SeWjfsRgc3hWCjvBkUdsmTKfU0tPbg1iTuEEjV5B338OW1K9MFccwTp1X6Qo7qiHmwzAQGg3uGh0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=GMcjywvj; arc=none smtp.client-ip=209.85.161.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="GMcjywvj" Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-657523b5db0so165556eaf.2 for ; Mon, 05 Jan 2026 15:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1767654594; x=1768259394; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7BfI8p5Sg/gvNukiFtFu/vPv9ZMQSyL6zAakTHxHqPk=; b=GMcjywvj0eVcWJ+mhdKworuuKpRddK3/pUdblBKr9rO+pszwMbAEbPPiNo4m3p0Fcd ul50D6HpXBxTWkZO7RpReNJ7I8dqFqDlwOfPflrEkev1qEsLgEyhTxAfgOZ/xru1UGyq 4M3BKhqMAle4HWh7XCjs0q36txrL1n+dbEVlt3EwlSM1g2omsHhY7gUJ7F6t2aUmH43X MrI3bWM+CklFbl2jOKpqaI7mfOkwNsf9rmakotlSnAkERdE7iDznb3KWVW33fhDl0tGe ORhNMXGVRf4+/BWhA34Kpx0Jvhak/b18ZfJmLwHE0JJfuvD2CvfwBsJb0k4zi99Ij5Bd E8/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767654594; x=1768259394; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7BfI8p5Sg/gvNukiFtFu/vPv9ZMQSyL6zAakTHxHqPk=; b=apzFGmrzjVhZjQrnWJRsGG+PaEFnGg6qkVq3AiiPeLnKEj8cLeJZtxF1yLdomZF78x paRcGpWBXb3CdTxds3VxciU/1lipO8zCH8S5sA5FxQRmUKcR8cAZPJw9bpgF236d7nf/ YfQSiFzp+AB+c8FHtAKC7CoBaQQwDZOtjmv+oLns3aRl9/tZ3IDPWXgkc+T2V9u7fPkV WRU2vfXNA/ZhfzslDt/mSzREqOKQ7E01zvxnPX2MerdFzUtn+VzC92NBatzyVzswy/ND i5FIvag5Y+JXOuwO6NjnFMS9o/EW6CLI8Mm7vD90hu9/3mdf/TJzW4hCoxBiOR8WpP4w KoFA== X-Forwarded-Encrypted: i=1; AJvYcCWBt1UPYbCzB/zpF0qVjHFGJX9mUPXnFoBBHbzmRxhBzBpd7dD3Anc8P7JcP+0AMyUdIM2z1cOnkiy/q8I=@vger.kernel.org X-Gm-Message-State: AOJu0YyFq6QzH0kgQ+vZTYFJpKMdRKCbEA85NVEl+morNumx8Ef1xZGy dVc/RlG6BFOfmNeRc7d5jZp1OJrQuopQguAWZtZ6gnAzgPlquKkPl1OYFW8KsxvkuY4= X-Gm-Gg: AY/fxX6/dwbeGMvfCenLi2Px6BeSWKKHxnjwXR6Yj/JCs9VCfHA7IMB+V5ySiiDLK4K QQX/ppxHkV6aH1FIb4c/mDo5iuPqVCvE/9boTi4CYhZqEC4krX0mMDw4Fa6rjkxfuCXiIBRJQ8B 7zyqGUTxriny3uA7kYNvchL0Gwab7b3qPNg3aMORjYUkwOKLTKmQlppJ8m10VqkHK9StVvi4B3T acr/9p7UxK8SIkWKDVOZfM7EI4HnZwQSAxCqW+kvixSkl/SPFRHpOOgi+fp4ld5BIjkQY90Xff8 5hF5caDNYY32uD0PjTXZziE/p8cBZKOKuAL0QeshKjvXmXcno97inXTcPLY5iiRv1JqNvIBeMIE f7Lv9ePbNcalReHHEWj4pBBNWa1SB0sDEVGFYyhlNVXZcUMY9/COcYIbIb9cK5jYOqA== X-Google-Smtp-Source: AGHT+IHvXL/KsqfHMGfaILEYbvXCIfRFUV+zAwS7sLeUwWiNFvLcGCxGKaIGOym3oFjVne8ZfPZqqA== X-Received: by 2002:a05:6820:1c91:b0:65b:32b4:840a with SMTP id 006d021491bc7-65f47a2fbe5mr601235eaf.51.1767654594081; Mon, 05 Jan 2026 15:09:54 -0800 (PST) Received: from CMGLRV3 ([2a09:bac5:947d:4e6::7d:88]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-65f48ab2d00sm251173eaf.0.2026.01.05.15.09.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 15:09:53 -0800 (PST) Date: Mon, 5 Jan 2026 17:09:51 -0600 From: Frederick Lawler To: Mimi Zohar Cc: Roberto Sassu , Dmitry Kasatkin , Eric Snowberg , Paul Moore , James Morris , "Serge E. Hallyn" , "Darrick J. Wong" , Christian Brauner , Josef Bacik , Jeff Layton , linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, kernel-team@cloudflare.com Subject: Re: [PATCH RFC] ima: Fallback to a ctime guard without i_version updates Message-ID: References: <20251229-xfs-ima-fixup-v1-1-6a717c939f7c@cloudflare.com> <4a4778ff395e533cad86ff3ffbf0ba90c3eb8798.camel@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a4778ff395e533cad86ff3ffbf0ba90c3eb8798.camel@linux.ibm.com> Hi Mimi, On Mon, Jan 05, 2026 at 05:15:15PM -0500, Mimi Zohar wrote: > 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. > Sure thing, I'll change for the v1. > 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. This was Jeff's suggestion. It does serve the purpose on saving some memory, but also has some value in the event nsec or sec is zero'd. It just needs to be different enough from the last cache'd evaluation. > > > > > 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 > > Signed-off-by: Frederick Lawler > > --- > > 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? > Kinda. The thought was to make already-audited files that have an unchanged i_version since last audit succeed early. Stacking tempfs on XFS for instance, would incur the stat cost each evaluation, since the cookie that used to set the i_version on evaluation with XFS on 6.12, is now always setting it to zero since 6.13. > > > > 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. > I was poking around last week at some testing platforms, and instead of adding to kernel sefltests & setup a VM etc..., to instead add to Linux Test Project (LTP) if that's fine? In any case, I can add my test snippet to v1, so you have something to review with the patch. That snippet works the same on 6.12 as it does on 6.19 with this patch. > thanks, > > Mimi