* [PATCH v6] ima_fs: Correctly create securityfs files for unsupported hash algos
From: Dmitry Safonov via B4 Relay @ 2026-03-10 17:40 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi
Cc: Jonathan McDowell, linux-integrity, linux-security-module,
linux-kernel, stable, Dmitry Safonov, Dmitry Safonov
From: Dmitry Safonov <dima@arista.com>
ima_tpm_chip->allocated_banks[i].crypto_id is initialized to
HASH_ALGO__LAST if the TPM algorithm is not supported. However there
are places relying on the algorithm to be valid because it is accessed
by hash_algo_name[].
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
==================================================================
BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
Call Trace:
<TASK>
dump_stack_lvl+0x61/0x90
print_report+0xc4/0x580
? kasan_addr_to_slab+0x26/0x80
? create_securityfs_measurement_lists+0x396/0x440
kasan_report+0xc2/0x100
? create_securityfs_measurement_lists+0x396/0x440
create_securityfs_measurement_lists+0x396/0x440
ima_fs_init+0xa3/0x300
ima_init+0x7d/0xd0
init_ima+0x28/0x100
do_one_initcall+0xa6/0x3e0
kernel_init_freeable+0x455/0x740
kernel_init+0x24/0x1d0
ret_from_fork+0x38/0x80
ret_from_fork_asm+0x11/0x20
</TASK>
The buggy address belongs to the variable:
hash_algo_name+0xb8/0x420
Memory state around the buggy address:
ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
^
ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
tpm tpm0: TPM with unsupported bank algorithm 0x0027
That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0
Library Part 2: Structures", page 51 [1].
See also the related U-Boot algorithms update [2].
Thus solve the problem by creating a file name with "_tpm_alg_<ID>"
postfix if the crypto algorithm isn't initialized.
This is how it looks on the test machine (patch ported to v6.12 release):
# ls -1 /sys/kernel/security/ima/
ascii_runtime_measurements
ascii_runtime_measurements_tpm_alg_27
ascii_runtime_measurements_sha1
ascii_runtime_measurements_sha256
binary_runtime_measurements
binary_runtime_measurements_tpm_alg_27
binary_runtime_measurements_sha1
binary_runtime_measurements_sha256
policy
runtime_measurements_count
violations
[1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf
[2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html
Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
Signed-off-by: Dmitry Safonov <dima@arista.com>
Cc: Enrico Bravi <enrico.bravi@polito.it>
Cc: Silvia Sisinni <silvia.sisinni@polito.it>
Cc: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
---
Changes in v6:
- Change subject now that securityfs files are created (Mimi Zohar)
- Added a link to TCG document and the related U-Boot changes
- Link to v5: https://lore.kernel.org/r/20260223-ima-oob-v5-1-91cc1064e767@arista.com
Changes in v5:
- Use lower-case for sysfs file name (as suggested-by Jonathan and Roberto)
- Don't use email quotes for patch description (Roberto)
- Re-word the patch description (suggested-by Roberto)
- Link to v4: https://lore.kernel.org/r/20260127-ima-oob-v4-1-bf0cd7f9b4d4@arista.com
Changes in v4:
- Use ima_tpm_chip->allocated_banks[algo_idx].digest_size instead of hash_digest_size[algo]
(Roberto Sassu)
- Link to v3: https://lore.kernel.org/r/20260127-ima-oob-v3-1-1dd09f4c2a6a@arista.com
Testing note: I test it on v6.12.40 kernel backport, which slightly differs as
lookup_template_data_hash_algo() was yet present.
Changes in v3:
- Now fix the spelling *for real* (sorry, messed it up in v2)
- Link to v2: https://lore.kernel.org/r/20260127-ima-oob-v2-1-f38a18c850cf@arista.com
Changes in v2:
- Instead of skipping unknown algorithms, add files under their TPM_ALG_ID (Roberto Sassu)
- Fix spelling (Roberto Sassu)
- Copy @stable on the fix
- Link to v1: https://lore.kernel.org/r/20260127-ima-oob-v1-1-2d42f3418e57@arista.com
---
security/integrity/ima/ima_fs.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index 23d3a14b8ce3..ca4931a95098 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -398,16 +398,24 @@ static int __init create_securityfs_measurement_lists(void)
char file_name[NAME_MAX + 1];
struct dentry *dentry;
- sprintf(file_name, "ascii_runtime_measurements_%s",
- hash_algo_name[algo]);
+ if (algo == HASH_ALGO__LAST)
+ sprintf(file_name, "ascii_runtime_measurements_tpm_alg_%x",
+ ima_tpm_chip->allocated_banks[i].alg_id);
+ else
+ sprintf(file_name, "ascii_runtime_measurements_%s",
+ hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
ima_dir, (void *)(uintptr_t)i,
&ima_ascii_measurements_ops);
if (IS_ERR(dentry))
return PTR_ERR(dentry);
- sprintf(file_name, "binary_runtime_measurements_%s",
- hash_algo_name[algo]);
+ if (algo == HASH_ALGO__LAST)
+ sprintf(file_name, "binary_runtime_measurements_tpm_alg_%x",
+ ima_tpm_chip->allocated_banks[i].alg_id);
+ else
+ sprintf(file_name, "binary_runtime_measurements_%s",
+ hash_algo_name[algo]);
dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
ima_dir, (void *)(uintptr_t)i,
&ima_measurements_ops);
---
base-commit: 343f51842f4ed7143872f3aa116a214a5619a4b9
change-id: 20260127-ima-oob-9fa83a634d7b
Best regards,
--
Dmitry Safonov <dima@arista.com>
^ permalink raw reply related
* Re: [PATCH 1/2] nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group()
From: Jeff Layton @ 2026-03-10 17:28 UTC (permalink / raw)
To: Viacheslav Dubeyko, Christian Brauner, Ryusuke Konishi,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
kernel test robot
In-Reply-To: <b0225cff966425a16213e2dae7cd30ba438e5af7.camel@dubeyko.com>
On Tue, 2026-03-10 at 09:54 -0700, Viacheslav Dubeyko wrote:
> On Tue, 2026-03-10 at 07:43 -0400, Jeff Layton wrote:
> > With the change to make inode->i_ino a u64, the build started failing
> > on
> > 32-bit ARM with:
> >
> > ERROR: modpost: "__aeabi_uldivmod" [fs/nilfs2/nilfs2.ko]
> > undefined!
> >
> > Fix this by using the 64-bit division interfaces in
> > nilfs_bmap_find_target_in_group().
> >
> > Fixes: 998a59d371c2 ("treewide: fix missed i_ino format specifier
> > conversions")
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes:
> > https://lore.kernel.org/oe-kbuild-all/202603100602.KPxiClIO-lkp@intel.com/
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/nilfs2/bmap.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/nilfs2/bmap.c b/fs/nilfs2/bmap.c
> > index
> > 824f2bd91c167965ec3a660202b6e6c5f1fe007e..4ce9a93149a5af13bc215cc1877
> > a757e2c6cf49b 100644
> > --- a/fs/nilfs2/bmap.c
> > +++ b/fs/nilfs2/bmap.c
> > @@ -455,11 +455,14 @@ __u64 nilfs_bmap_find_target_in_group(const
> > struct nilfs_bmap *bmap)
> > {
> > struct inode *dat = nilfs_bmap_get_dat(bmap);
> > unsigned long entries_per_group =
> > nilfs_palloc_entries_per_group(dat);
> > - unsigned long group = bmap->b_inode->i_ino /
> > entries_per_group;
> > + unsigned long group;
> > + u32 rem;
> > +
> > + group = div_u64(bmap->b_inode->i_ino, entries_per_group);
> > + div_u64_rem(bmap->b_inode->i_ino, NILFS_BMAP_GROUP_DIV,
> > &rem);
> >
> > return group * entries_per_group +
> > - (bmap->b_inode->i_ino % NILFS_BMAP_GROUP_DIV) *
> > - (entries_per_group / NILFS_BMAP_GROUP_DIV);
> > + rem * (entries_per_group / NILFS_BMAP_GROUP_DIV);
> > }
> >
> > static struct lock_class_key nilfs_bmap_dat_lock_key;
>
> Makes sense. :) Maybe, rem is not very good variable name, but the
> whole logic looks good.
>
> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
>
Thanks. My thinking was "remainder" but I don't have an objection if
you guys want to change it.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group()
From: Viacheslav Dubeyko @ 2026-03-10 16:54 UTC (permalink / raw)
To: Jeff Layton, Christian Brauner, Ryusuke Konishi, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Paul Moore,
James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
kernel test robot
In-Reply-To: <20260310-iino-u64-v1-1-18422a053b04@kernel.org>
On Tue, 2026-03-10 at 07:43 -0400, Jeff Layton wrote:
> With the change to make inode->i_ino a u64, the build started failing
> on
> 32-bit ARM with:
>
> ERROR: modpost: "__aeabi_uldivmod" [fs/nilfs2/nilfs2.ko]
> undefined!
>
> Fix this by using the 64-bit division interfaces in
> nilfs_bmap_find_target_in_group().
>
> Fixes: 998a59d371c2 ("treewide: fix missed i_ino format specifier
> conversions")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202603100602.KPxiClIO-lkp@intel.com/
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/nilfs2/bmap.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nilfs2/bmap.c b/fs/nilfs2/bmap.c
> index
> 824f2bd91c167965ec3a660202b6e6c5f1fe007e..4ce9a93149a5af13bc215cc1877
> a757e2c6cf49b 100644
> --- a/fs/nilfs2/bmap.c
> +++ b/fs/nilfs2/bmap.c
> @@ -455,11 +455,14 @@ __u64 nilfs_bmap_find_target_in_group(const
> struct nilfs_bmap *bmap)
> {
> struct inode *dat = nilfs_bmap_get_dat(bmap);
> unsigned long entries_per_group =
> nilfs_palloc_entries_per_group(dat);
> - unsigned long group = bmap->b_inode->i_ino /
> entries_per_group;
> + unsigned long group;
> + u32 rem;
> +
> + group = div_u64(bmap->b_inode->i_ino, entries_per_group);
> + div_u64_rem(bmap->b_inode->i_ino, NILFS_BMAP_GROUP_DIV,
> &rem);
>
> return group * entries_per_group +
> - (bmap->b_inode->i_ino % NILFS_BMAP_GROUP_DIV) *
> - (entries_per_group / NILFS_BMAP_GROUP_DIV);
> + rem * (entries_per_group / NILFS_BMAP_GROUP_DIV);
> }
>
> static struct lock_class_key nilfs_bmap_dat_lock_key;
Makes sense. :) Maybe, rem is not very good variable name, but the
whole logic looks good.
Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
Thanks,
Slava.
^ permalink raw reply
* Re: [PATCH 2/2] EVM: add comment describing why ino field is still unsigned long
From: Mimi Zohar @ 2026-03-10 16:05 UTC (permalink / raw)
To: Jeff Layton, Christian Brauner, Ryusuke Konishi,
Viacheslav Dubeyko, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module
In-Reply-To: <20260310-iino-u64-v1-2-18422a053b04@kernel.org>
On Tue, 2026-03-10 at 07:43 -0400, Jeff Layton wrote:
> Mimi pointed out that we didn't widen the inode number field in struct
> h_misc alongside the inode->i_ino widening. While we could make an
> equivalent change there, that would force EVM remeasurement on all
> 32-bit hosts.
Instead of saying "force EVM remeasurement" say, "require EVM resigning".
>
> Instead, leave the field as an unsigned long. This should have no effect
> on 64-bit hosts, and allow things to continue working on 32-bit hosts in
> the cases where the i_ino fits in 32-bits.
>
> Add a comment explaining why it's being left as unsigned long.
>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> security/integrity/evm/evm_crypto.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index c0ca4eedb0fe5d5c30f45f515a4bc90248ec64ea..3445f4c2097f7e8af61de6299b721fc4a1d8afb4 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -144,6 +144,12 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> char type, char *digest)
> {
> struct h_misc {
> + /*
> + * Although inode->i_ino is now u64, this field remains
> + * unsigned long to allow existing hashes from 32-bit hosts
> + * to continue working when i_ino hasn't changed and fitsxi
> + * in a u32.
security.evm contains either an HMAC or signature. Change "hashes" -> HMAC and
signatures"
Mimi
> + */
> unsigned long ino;
> __u32 generation;
> uid_t uid;
^ permalink raw reply
* Re: [PATCH 1/2] nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group()
From: Ryusuke Konishi @ 2026-03-10 13:01 UTC (permalink / raw)
To: Jeff Layton
Cc: Christian Brauner, Viacheslav Dubeyko, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, linux-nilfs, linux-kernel, linux-integrity,
linux-security-module, kernel test robot
In-Reply-To: <20260310-iino-u64-v1-1-18422a053b04@kernel.org>
On Tue, Mar 10, 2026 at 8:44 PM Jeff Layton wrote:
>
> With the change to make inode->i_ino a u64, the build started failing on
> 32-bit ARM with:
>
> ERROR: modpost: "__aeabi_uldivmod" [fs/nilfs2/nilfs2.ko] undefined!
>
> Fix this by using the 64-bit division interfaces in
> nilfs_bmap_find_target_in_group().
>
> Fixes: 998a59d371c2 ("treewide: fix missed i_ino format specifier conversions")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603100602.KPxiClIO-lkp@intel.com/
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Thank you. The conversion seems reasonable.
Ryusuke Konishi
> ---
> fs/nilfs2/bmap.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nilfs2/bmap.c b/fs/nilfs2/bmap.c
> index 824f2bd91c167965ec3a660202b6e6c5f1fe007e..4ce9a93149a5af13bc215cc1877a757e2c6cf49b 100644
> --- a/fs/nilfs2/bmap.c
> +++ b/fs/nilfs2/bmap.c
> @@ -455,11 +455,14 @@ __u64 nilfs_bmap_find_target_in_group(const struct nilfs_bmap *bmap)
> {
> struct inode *dat = nilfs_bmap_get_dat(bmap);
> unsigned long entries_per_group = nilfs_palloc_entries_per_group(dat);
> - unsigned long group = bmap->b_inode->i_ino / entries_per_group;
> + unsigned long group;
> + u32 rem;
> +
> + group = div_u64(bmap->b_inode->i_ino, entries_per_group);
> + div_u64_rem(bmap->b_inode->i_ino, NILFS_BMAP_GROUP_DIV, &rem);
>
> return group * entries_per_group +
> - (bmap->b_inode->i_ino % NILFS_BMAP_GROUP_DIV) *
> - (entries_per_group / NILFS_BMAP_GROUP_DIV);
> + rem * (entries_per_group / NILFS_BMAP_GROUP_DIV);
> }
>
> static struct lock_class_key nilfs_bmap_dat_lock_key;
>
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH 2/2] EVM: add comment describing why ino field is still unsigned long
From: Jeff Layton @ 2026-03-10 11:43 UTC (permalink / raw)
To: Christian Brauner, Ryusuke Konishi, Viacheslav Dubeyko,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
Jeff Layton
In-Reply-To: <20260310-iino-u64-v1-0-18422a053b04@kernel.org>
Mimi pointed out that we didn't widen the inode number field in struct
h_misc alongside the inode->i_ino widening. While we could make an
equivalent change there, that would force EVM remeasurement on all
32-bit hosts.
Instead, leave the field as an unsigned long. This should have no effect
on 64-bit hosts, and allow things to continue working on 32-bit hosts in
the cases where the i_ino fits in 32-bits.
Add a comment explaining why it's being left as unsigned long.
Cc: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
security/integrity/evm/evm_crypto.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index c0ca4eedb0fe5d5c30f45f515a4bc90248ec64ea..3445f4c2097f7e8af61de6299b721fc4a1d8afb4 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -144,6 +144,12 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
char type, char *digest)
{
struct h_misc {
+ /*
+ * Although inode->i_ino is now u64, this field remains
+ * unsigned long to allow existing hashes from 32-bit hosts
+ * to continue working when i_ino hasn't changed and fitsxi
+ * in a u32.
+ */
unsigned long ino;
__u32 generation;
uid_t uid;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group()
From: Jeff Layton @ 2026-03-10 11:43 UTC (permalink / raw)
To: Christian Brauner, Ryusuke Konishi, Viacheslav Dubeyko,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
Jeff Layton, kernel test robot
In-Reply-To: <20260310-iino-u64-v1-0-18422a053b04@kernel.org>
With the change to make inode->i_ino a u64, the build started failing on
32-bit ARM with:
ERROR: modpost: "__aeabi_uldivmod" [fs/nilfs2/nilfs2.ko] undefined!
Fix this by using the 64-bit division interfaces in
nilfs_bmap_find_target_in_group().
Fixes: 998a59d371c2 ("treewide: fix missed i_ino format specifier conversions")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603100602.KPxiClIO-lkp@intel.com/
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/nilfs2/bmap.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/nilfs2/bmap.c b/fs/nilfs2/bmap.c
index 824f2bd91c167965ec3a660202b6e6c5f1fe007e..4ce9a93149a5af13bc215cc1877a757e2c6cf49b 100644
--- a/fs/nilfs2/bmap.c
+++ b/fs/nilfs2/bmap.c
@@ -455,11 +455,14 @@ __u64 nilfs_bmap_find_target_in_group(const struct nilfs_bmap *bmap)
{
struct inode *dat = nilfs_bmap_get_dat(bmap);
unsigned long entries_per_group = nilfs_palloc_entries_per_group(dat);
- unsigned long group = bmap->b_inode->i_ino / entries_per_group;
+ unsigned long group;
+ u32 rem;
+
+ group = div_u64(bmap->b_inode->i_ino, entries_per_group);
+ div_u64_rem(bmap->b_inode->i_ino, NILFS_BMAP_GROUP_DIV, &rem);
return group * entries_per_group +
- (bmap->b_inode->i_ino % NILFS_BMAP_GROUP_DIV) *
- (entries_per_group / NILFS_BMAP_GROUP_DIV);
+ rem * (entries_per_group / NILFS_BMAP_GROUP_DIV);
}
static struct lock_class_key nilfs_bmap_dat_lock_key;
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] vfs: follow-on fixes for i_ino widening
From: Jeff Layton @ 2026-03-10 11:43 UTC (permalink / raw)
To: Christian Brauner, Ryusuke Konishi, Viacheslav Dubeyko,
Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-nilfs, linux-kernel, linux-integrity, linux-security-module,
Jeff Layton, kernel test robot
Just some patches to fix follow-on issues reported after the
inode->i_ino widening series. Christian, please toss these onto
vfs-7.1.kino, assuming they pass review.
Thanks,
Jeff
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Jeff Layton (2):
nilfs2: fix 64-bit division operations in nilfs_bmap_find_target_in_group()
EVM: add comment describing why ino field is still unsigned long
fs/nilfs2/bmap.c | 9 ++++++---
security/integrity/evm/evm_crypto.c | 6 ++++++
2 files changed, 12 insertions(+), 3 deletions(-)
---
base-commit: 9840bb66e7e5dffd72b03201318f154a10b06b4a
change-id: 20260310-iino-u64-424fa570d850
Best regards,
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] keys/trusted_keys: clean up debug message logging in the tpm backend
From: Nayna Jain @ 2026-03-09 22:45 UTC (permalink / raw)
To: Srish Srinivasan, linux-integrity, keyrings
Cc: James.Bottomley, jarkko, zohar, stefanb, linux-kernel,
linux-security-module
In-Reply-To: <20260220183426.80446-2-ssrish@linux.ibm.com>
On 2/20/26 1:34 PM, Srish Srinivasan wrote:
> The TPM trusted-keys backend uses a local TPM_DEBUG guard and pr_info()
> for logging debug information.
>
> Replace pr_info() with pr_debug(), and use KERN_DEBUG for print_hex_dump().
> Remove TPM_DEBUG.
>
> No functional change intended.
There is functional change here. This change allows secret and nonce in
the function dump_sess() to be logged to kernel logs when dynamic debug
is enabled. Previously, it was possible only in the debug builds and not
the production builds at runtime. With this change, it is always there
in production build. This can result in possible attack.
Instead of doing this change, I think add a comment to prevent this sort
of change in the future.
Thanks & Regards,
- Nayna
>
> Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
> ---
> security/keys/trusted-keys/trusted_tpm1.c | 40 +++++++----------------
> 1 file changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index c865c97aa1b4..216caef97ffc 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -46,28 +46,25 @@ enum {
> SRK_keytype = 4
> };
>
> -#define TPM_DEBUG 0
> -
> -#if TPM_DEBUG
> static inline void dump_options(struct trusted_key_options *o)
> {
> - pr_info("sealing key type %d\n", o->keytype);
> - pr_info("sealing key handle %0X\n", o->keyhandle);
> - pr_info("pcrlock %d\n", o->pcrlock);
> - pr_info("pcrinfo %d\n", o->pcrinfo_len);
> - print_hex_dump(KERN_INFO, "pcrinfo ", DUMP_PREFIX_NONE,
> + pr_debug("sealing key type %d\n", o->keytype);
> + pr_debug("sealing key handle %0X\n", o->keyhandle);
> + pr_debug("pcrlock %d\n", o->pcrlock);
> + pr_debug("pcrinfo %d\n", o->pcrinfo_len);
> + print_hex_dump(KERN_DEBUG, "pcrinfo ", DUMP_PREFIX_NONE,
> 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> }
>
> static inline void dump_sess(struct osapsess *s)
> {
> - print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> + print_hex_dump(KERN_DEBUG, "trusted-key: handle ", DUMP_PREFIX_NONE,
> 16, 1, &s->handle, 4, 0);
> - pr_info("secret:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> + pr_debug("secret:\n");
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE,
> 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
> - pr_info("trusted-key: enonce:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> + pr_debug("trusted-key: enonce:\n");
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE,
> 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
> }
>
> @@ -75,23 +72,10 @@ static inline void dump_tpm_buf(unsigned char *buf)
> {
> int len;
>
> - pr_info("\ntpm buffer\n");
> + pr_debug("\ntpm buffer\n");
> len = LOAD32(buf, TPM_SIZE_OFFSET);
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> -}
> -#else
> -static inline void dump_options(struct trusted_key_options *o)
> -{
> -}
> -
> -static inline void dump_sess(struct osapsess *s)
> -{
> -}
> -
> -static inline void dump_tpm_buf(unsigned char *buf)
> -{
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> }
> -#endif
>
> static int TSS_rawhmac(unsigned char *digest, const unsigned char *key,
> unsigned int keylen, ...)
^ permalink raw reply
* Re: [PATCH] integrity: avoid using __weak functions
From: Nathan Chancellor @ 2026-03-09 21:29 UTC (permalink / raw)
To: Mimi Zohar
Cc: Arnd Bergmann, Madhavan Srinivasan, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, Arnd Bergmann,
Roberto Sassu, Dmitry Kasatkin, Paul Moore, James Morris,
Serge E. Hallyn, Jarkko Sakkinen, Ard Biesheuvel, Coiby Xu,
Nicholas Piggin, Christophe Leroy (CS GROUP),
Christian Borntraeger, Sven Schnelle, Eric Snowberg,
Nick Desaulniers, Bill Wendling, Justin Stitt, Andrew Donnellan,
linuxppc-dev, linux-kernel, linux-s390, linux-arch,
linux-integrity, linux-security-module, keyrings, llvm
In-Reply-To: <abb4d186d1ca76c080d5e15bcd9e0019cce3af39.camel@linux.ibm.com>
On Sun, Mar 08, 2026 at 09:01:58PM -0400, Mimi Zohar wrote:
> Thanks Arnd, Nathan. LGTM. Nathan, could you send a patch with a proper patch
> description.
Done, thanks for the input!
https://lore.kernel.org/20260309-integrity-drop-weak-arch-get-secureboot-v1-1-6460d5c4bb89@kernel.org/
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Jeff Layton @ 2026-03-09 20:50 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <0bd92b4fce00a6111a0fc7764904f7e6ae0ece3a.camel@linux.ibm.com>
On Mon, 2026-03-09 at 16:11 -0400, Mimi Zohar wrote:
> On Mon, 2026-03-09 at 15:33 -0400, Jeff Layton wrote:
> > On Mon, 2026-03-09 at 15:00 -0400, Mimi Zohar wrote:
> > > On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> > > > On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > > > > [ I/O socket time out. Trimming the To list.]
> > > > >
> > > > > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > > > > This version squashes all of the format-string changes and the i_ino
> > > > > > type change into the same patch. This results in a giant 600+ line patch
> > > > > > at the end of the series, but it does remain bisectable. Because the
> > > > > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > > > > dropped.
> > > > > >
> > > > > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > > > > interested in testing this.
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > > > > >
> > > > > > Original cover letter follows:
> > > > > >
> > > > > > ----------------------8<-----------------------
> > > > > >
> > > > > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > > > > >
> > > > > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > > > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > > > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > > > > into a 32-bit field, and deprives us of a universal identifier field for
> > > > > > an inode.
> > > > > >
> > > > > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > > > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > > > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > > > > have effects on slabcache sizes and field alignment.
> > > > > >
> > > > > > The bulk of the changes are to format strings and tracepoints, since the
> > > > > > kernel itself doesn't care that much about the i_ino field. The first
> > > > > > patch changes some vfs function arguments, so check that one out
> > > > > > carefully.
> > > > > >
> > > > > > With this change, we may be able to shrink some inode structures. For
> > > > > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > > > > inode number. With this set of changes, that field could be eliminated.
> > > > > > I'd rather leave that sort of cleanups for later just to keep this
> > > > > > simple.
> > > > > >
> > > > > > Much of this set was generated by LLM, but I attributed it to myself
> > > > > > since I consider this to be in the "menial tasks" category of LLM usage.
> > > > > >
> > > > > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > > > > >
> > > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > >
> > > > > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > > > > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > > > > signed.
> > > > >
> > > > >
> > > >
> > > > Thanks Mimi, good catch.
> > > >
> > > > It looks like we should just be able to change the ino field to a u64
> > > > alongside everything else. Something like this:
> > > >
> > > > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > > > index c0ca4eedb0fe..77b6c2fa345e 100644
> > > > --- a/security/integrity/evm/evm_crypto.c
> > > > +++ b/security/integrity/evm/evm_crypto.c
> > > > @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> > > > char type, char *digest)
> > > > {
> > > > struct h_misc {
> > > > - unsigned long ino;
> > > > + u64 ino;
> > > > __u32 generation;
> > > > uid_t uid;
> > > > gid_t gid;
> > > >
> > >
> > > Agreed.
> > >
> > > >
> > > > That should make no material difference on 64-bit hosts. What's the
> > > > effect on 32-bit? Will they just need to remeasure everything or would
> > > > the consequences be more dire? Do we have any clue whether anyone is
> > > > using EVM in 32-bit environments?
> > >
> > > All good questions. Unfortunately I don't know the answer to most of them. What
> > > we do know: changing the size of the i_ino field would affect EVM file metadata
> > > verification and would require relabeling the filesystem. Even packages
> > > containing EVM portable signatures, which don't include or verify the i_ino
> > > number, would be affected.
> > >
> >
> > Ouch. Technically, I guess this is ABI...
> >
> > While converting to u64 seems like the ideal thing to do, the other
> > option might be to just keep this as an unsigned long for now.
> >
> > No effect on 64-bit, but that could keep things working 32-bit when the
> > i_ino casts properly to a u32. ext4 would be fine since they don't
> > issue inode numbers larger than UINT_MAX. xfs and btrfs are a bit more
> > iffy, but worst case they'd just need to be relabeled (which is what
> > they'll need to do anyway).
> >
> > If we do that, then we should probably add a comment to this function
> > explaining why it's an unsigned long.
>
> Agreed.
>
For now, I think that's the best approach. I'll spin up a patch to add
the comment.
> >
> > Thoughts?
>
> My concern would be embedded/IoT devices, but I don't have any insight into who
> might be using it on 32 bit.
>
Yep. This LWN article on Arnd's talk lays out the state of things:
https://lwn.net/Articles/1035727/
The upshot is that it's hard to buy 32-bit CPUs these days, and will
only get harder. But, there are still a fair number of 32-bit devices
out in the field and will be for some time.
The big question is how many of those EVM users that intend to run new
kernels. I have no idea how to answer that.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH] integrity: Eliminate weak definition of arch_get_secureboot()
From: Nathan Chancellor @ 2026-03-09 20:37 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg
Cc: Arnd Bergmann, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Paul Moore, James Morris, Serge E. Hallyn,
Coiby Xu, linux-kernel, linuxppc-dev, linux-s390, linux-integrity,
linux-security-module, llvm, Nathan Chancellor
security/integrity/secure_boot.c contains a single __weak function,
which breaks recordmcount when building with clang:
$ make -skj"$(nproc)" ARCH=powerpc LLVM=1 ppc64_defconfig security/integrity/secure_boot.o
Cannot find symbol for section 2: .text.
security/integrity/secure_boot.o: failed
Introduce a Kconfig symbol, CONFIG_HAVE_ARCH_GET_SECUREBOOT, to indicate
that an architecture provides a definition of arch_get_secureboot().
Provide a static inline stub when this symbol is not defined to achieve
the same effect as the __weak function, allowing secure_boot.c to be
removed altogether. Move the s390 definition of arch_get_secureboot()
out of the CONFIG_KEXEC_FILE block to ensure it is always available, as
it does not actually depend on KEXEC_FILE.
Fixes: 31a6a07eefeb ("integrity: Make arch_ima_get_secureboot integrity-wide")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
arch/Kconfig | 3 +++
arch/powerpc/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/s390/kernel/ipl.c | 10 +++++-----
include/linux/secure_boot.h | 4 ++++
security/integrity/Makefile | 2 +-
security/integrity/secure_boot.c | 16 ----------------
7 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 102ddbd4298e..a6d1c8cc1d64 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1841,4 +1841,7 @@ config ARCH_WANTS_PRE_LINK_VMLINUX
config ARCH_HAS_CPU_ATTACK_VECTORS
bool
+config HAVE_ARCH_GET_SECUREBOOT
+ def_bool EFI
+
endmenu
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ad7a2fe63a2a..da1eafb64354 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1061,6 +1061,7 @@ config PPC_SECURE_BOOT
depends on IMA_ARCH_POLICY
imply IMA_SECURE_AND_OR_TRUSTED_BOOT
select PSERIES_PLPKS if PPC_PSERIES
+ select HAVE_ARCH_GET_SECUREBOOT
help
Systems with firmware secure boot enabled need to define security
policies to extend secure boot to the OS. This config allows a user
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 2101cc738b5e..4197c20d34b4 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -181,6 +181,7 @@ config S390
select GENERIC_IOREMAP if PCI
select HAVE_ALIGNED_STRUCT_PAGE
select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_GET_SECUREBOOT
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN
diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index 2d01a1713938..3c346b02ceb9 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -2388,6 +2388,11 @@ void __no_stack_protector s390_reset_system(void)
diag_amode31_ops.diag308_reset();
}
+bool arch_get_secureboot(void)
+{
+ return ipl_secure_flag;
+}
+
#ifdef CONFIG_KEXEC_FILE
int ipl_report_add_component(struct ipl_report *report, struct kexec_buf *kbuf,
@@ -2505,11 +2510,6 @@ void *ipl_report_finish(struct ipl_report *report)
return buf;
}
-bool arch_get_secureboot(void)
-{
- return ipl_secure_flag;
-}
-
int ipl_report_free(struct ipl_report *report)
{
struct ipl_report_component *comp, *ncomp;
diff --git a/include/linux/secure_boot.h b/include/linux/secure_boot.h
index 3ded3f03655c..d17e92351567 100644
--- a/include/linux/secure_boot.h
+++ b/include/linux/secure_boot.h
@@ -10,10 +10,14 @@
#include <linux/types.h>
+#ifdef CONFIG_HAVE_ARCH_GET_SECUREBOOT
/*
* Returns true if the platform secure boot is enabled.
* Returns false if disabled or not supported.
*/
bool arch_get_secureboot(void);
+#else
+static inline bool arch_get_secureboot(void) { return false; }
+#endif
#endif /* _LINUX_SECURE_BOOT_H */
diff --git a/security/integrity/Makefile b/security/integrity/Makefile
index 548665e2b702..45dfdedbdad4 100644
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -5,7 +5,7 @@
obj-$(CONFIG_INTEGRITY) += integrity.o
-integrity-y := iint.o secure_boot.o
+integrity-y := iint.o
integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
diff --git a/security/integrity/secure_boot.c b/security/integrity/secure_boot.c
deleted file mode 100644
index fc2693c286f8..000000000000
--- a/security/integrity/secure_boot.c
+++ /dev/null
@@ -1,16 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2026 Red Hat, Inc. All Rights Reserved.
- *
- * Author: Coiby Xu <coxu@redhat.com>
- */
-#include <linux/secure_boot.h>
-
-/*
- * Default weak implementation.
- * Architectures that support secure boot must override this.
- */
-__weak bool arch_get_secureboot(void)
-{
- return false;
-}
---
base-commit: 870819434c8dfcc3158033b66e7851b81bb17e21
change-id: 20260309-integrity-drop-weak-arch-get-secureboot-cead298d493f
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply related
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Mimi Zohar @ 2026-03-09 20:11 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <dd3f9873c7939fba0ca2366effd24e4b6326f17b.camel@kernel.org>
On Mon, 2026-03-09 at 15:33 -0400, Jeff Layton wrote:
> On Mon, 2026-03-09 at 15:00 -0400, Mimi Zohar wrote:
> > On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> > > On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > > > [ I/O socket time out. Trimming the To list.]
> > > >
> > > > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > > > This version squashes all of the format-string changes and the i_ino
> > > > > type change into the same patch. This results in a giant 600+ line patch
> > > > > at the end of the series, but it does remain bisectable. Because the
> > > > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > > > dropped.
> > > > >
> > > > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > > > interested in testing this.
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > > > >
> > > > > Original cover letter follows:
> > > > >
> > > > > ----------------------8<-----------------------
> > > > >
> > > > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > > > >
> > > > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > > > into a 32-bit field, and deprives us of a universal identifier field for
> > > > > an inode.
> > > > >
> > > > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > > > have effects on slabcache sizes and field alignment.
> > > > >
> > > > > The bulk of the changes are to format strings and tracepoints, since the
> > > > > kernel itself doesn't care that much about the i_ino field. The first
> > > > > patch changes some vfs function arguments, so check that one out
> > > > > carefully.
> > > > >
> > > > > With this change, we may be able to shrink some inode structures. For
> > > > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > > > inode number. With this set of changes, that field could be eliminated.
> > > > > I'd rather leave that sort of cleanups for later just to keep this
> > > > > simple.
> > > > >
> > > > > Much of this set was generated by LLM, but I attributed it to myself
> > > > > since I consider this to be in the "menial tasks" category of LLM usage.
> > > > >
> > > > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > > > >
> > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > >
> > > > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > > > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > > > signed.
> > > >
> > > >
> > >
> > > Thanks Mimi, good catch.
> > >
> > > It looks like we should just be able to change the ino field to a u64
> > > alongside everything else. Something like this:
> > >
> > > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > > index c0ca4eedb0fe..77b6c2fa345e 100644
> > > --- a/security/integrity/evm/evm_crypto.c
> > > +++ b/security/integrity/evm/evm_crypto.c
> > > @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> > > char type, char *digest)
> > > {
> > > struct h_misc {
> > > - unsigned long ino;
> > > + u64 ino;
> > > __u32 generation;
> > > uid_t uid;
> > > gid_t gid;
> > >
> >
> > Agreed.
> >
> > >
> > > That should make no material difference on 64-bit hosts. What's the
> > > effect on 32-bit? Will they just need to remeasure everything or would
> > > the consequences be more dire? Do we have any clue whether anyone is
> > > using EVM in 32-bit environments?
> >
> > All good questions. Unfortunately I don't know the answer to most of them. What
> > we do know: changing the size of the i_ino field would affect EVM file metadata
> > verification and would require relabeling the filesystem. Even packages
> > containing EVM portable signatures, which don't include or verify the i_ino
> > number, would be affected.
> >
>
> Ouch. Technically, I guess this is ABI...
>
> While converting to u64 seems like the ideal thing to do, the other
> option might be to just keep this as an unsigned long for now.
>
> No effect on 64-bit, but that could keep things working 32-bit when the
> i_ino casts properly to a u32. ext4 would be fine since they don't
> issue inode numbers larger than UINT_MAX. xfs and btrfs are a bit more
> iffy, but worst case they'd just need to be relabeled (which is what
> they'll need to do anyway).
>
> If we do that, then we should probably add a comment to this function
> explaining why it's an unsigned long.
Agreed.
>
> Thoughts?
My concern would be embedded/IoT devices, but I don't have any insight into who
might be using it on 32 bit.
Mimi
^ permalink raw reply
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Jeff Layton @ 2026-03-09 19:33 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <c9500adc562665d44feaca9206f23a5ba07432c1.camel@linux.ibm.com>
On Mon, 2026-03-09 at 15:00 -0400, Mimi Zohar wrote:
> On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> > On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > > [ I/O socket time out. Trimming the To list.]
> > >
> > > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > > This version squashes all of the format-string changes and the i_ino
> > > > type change into the same patch. This results in a giant 600+ line patch
> > > > at the end of the series, but it does remain bisectable. Because the
> > > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > > dropped.
> > > >
> > > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > > interested in testing this.
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > > >
> > > > Original cover letter follows:
> > > >
> > > > ----------------------8<-----------------------
> > > >
> > > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > > >
> > > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > > into a 32-bit field, and deprives us of a universal identifier field for
> > > > an inode.
> > > >
> > > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > > have effects on slabcache sizes and field alignment.
> > > >
> > > > The bulk of the changes are to format strings and tracepoints, since the
> > > > kernel itself doesn't care that much about the i_ino field. The first
> > > > patch changes some vfs function arguments, so check that one out
> > > > carefully.
> > > >
> > > > With this change, we may be able to shrink some inode structures. For
> > > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > > inode number. With this set of changes, that field could be eliminated.
> > > > I'd rather leave that sort of cleanups for later just to keep this
> > > > simple.
> > > >
> > > > Much of this set was generated by LLM, but I attributed it to myself
> > > > since I consider this to be in the "menial tasks" category of LLM usage.
> > > >
> > > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > > >
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > >
> > > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > > signed.
> > >
> > >
> >
> > Thanks Mimi, good catch.
> >
> > It looks like we should just be able to change the ino field to a u64
> > alongside everything else. Something like this:
> >
> > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > index c0ca4eedb0fe..77b6c2fa345e 100644
> > --- a/security/integrity/evm/evm_crypto.c
> > +++ b/security/integrity/evm/evm_crypto.c
> > @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> > char type, char *digest)
> > {
> > struct h_misc {
> > - unsigned long ino;
> > + u64 ino;
> > __u32 generation;
> > uid_t uid;
> > gid_t gid;
> >
>
> Agreed.
>
> >
> > That should make no material difference on 64-bit hosts. What's the
> > effect on 32-bit? Will they just need to remeasure everything or would
> > the consequences be more dire? Do we have any clue whether anyone is
> > using EVM in 32-bit environments?
>
> All good questions. Unfortunately I don't know the answer to most of them. What
> we do know: changing the size of the i_ino field would affect EVM file metadata
> verification and would require relabeling the filesystem. Even packages
> containing EVM portable signatures, which don't include or verify the i_ino
> number, would be affected.
>
Ouch. Technically, I guess this is ABI...
While converting to u64 seems like the ideal thing to do, the other
option might be to just keep this as an unsigned long for now.
No effect on 64-bit, but that could keep things working 32-bit when the
i_ino casts properly to a u32. ext4 would be fine since they don't
issue inode numbers larger than UINT_MAX. xfs and btrfs are a bit more
iffy, but worst case they'd just need to be relabeled (which is what
they'll need to do anyway).
If we do that, then we should probably add a comment to this function
explaining why it's an unsigned long.
Thoughts?
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Mimi Zohar @ 2026-03-09 19:00 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <f22758116dabd3c135a833bcb5cfcd2ea4f6ecf4.camel@kernel.org>
On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote:
> On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> > [ I/O socket time out. Trimming the To list.]
> >
> > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > > This version squashes all of the format-string changes and the i_ino
> > > type change into the same patch. This results in a giant 600+ line patch
> > > at the end of the series, but it does remain bisectable. Because the
> > > patchset was reorganized (again) some of the R-b's and A-b's have been
> > > dropped.
> > >
> > > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > > interested in testing this.
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> > >
> > > Original cover letter follows:
> > >
> > > ----------------------8<-----------------------
> > >
> > > Christian said [1] to "just do it" when I proposed this, so here we are!
> > >
> > > For historical reasons, the inode->i_ino field is an unsigned long,
> > > which means that it's 32 bits on 32 bit architectures. This has caused a
> > > number of filesystems to implement hacks to hash a 64-bit identifier
> > > into a 32-bit field, and deprives us of a universal identifier field for
> > > an inode.
> > >
> > > This patchset changes the inode->i_ino field from an unsigned long to a
> > > u64. This shouldn't make any material difference on 64-bit hosts, but
> > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > > have effects on slabcache sizes and field alignment.
> > >
> > > The bulk of the changes are to format strings and tracepoints, since the
> > > kernel itself doesn't care that much about the i_ino field. The first
> > > patch changes some vfs function arguments, so check that one out
> > > carefully.
> > >
> > > With this change, we may be able to shrink some inode structures. For
> > > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > > inode number. With this set of changes, that field could be eliminated.
> > > I'd rather leave that sort of cleanups for later just to keep this
> > > simple.
> > >
> > > Much of this set was generated by LLM, but I attributed it to myself
> > > since I consider this to be in the "menial tasks" category of LLM usage.
> > >
> > > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> > >
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> >
> > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> > i_ino and calculates either an HMAC or file meta-data hash, which is then
> > signed.
> >
> >
>
> Thanks Mimi, good catch.
>
> It looks like we should just be able to change the ino field to a u64
> alongside everything else. Something like this:
>
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index c0ca4eedb0fe..77b6c2fa345e 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> char type, char *digest)
> {
> struct h_misc {
> - unsigned long ino;
> + u64 ino;
> __u32 generation;
> uid_t uid;
> gid_t gid;
>
Agreed.
>
> That should make no material difference on 64-bit hosts. What's the
> effect on 32-bit? Will they just need to remeasure everything or would
> the consequences be more dire? Do we have any clue whether anyone is
> using EVM in 32-bit environments?
All good questions. Unfortunately I don't know the answer to most of them. What
we do know: changing the size of the i_ino field would affect EVM file metadata
verification and would require relabeling the filesystem. Even packages
containing EVM portable signatures, which don't include or verify the i_ino
number, would be affected.
Mimi
^ permalink raw reply
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Jeff Layton @ 2026-03-09 17:59 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <05b5d55c49b5a1bbc43a5315e3c84872e7e634b3.camel@linux.ibm.com>
On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> [ I/O socket time out. Trimming the To list.]
>
> On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> > This version squashes all of the format-string changes and the i_ino
> > type change into the same patch. This results in a giant 600+ line patch
> > at the end of the series, but it does remain bisectable. Because the
> > patchset was reorganized (again) some of the R-b's and A-b's have been
> > dropped.
> >
> > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > interested in testing this.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> >
> > Original cover letter follows:
> >
> > ----------------------8<-----------------------
> >
> > Christian said [1] to "just do it" when I proposed this, so here we are!
> >
> > For historical reasons, the inode->i_ino field is an unsigned long,
> > which means that it's 32 bits on 32 bit architectures. This has caused a
> > number of filesystems to implement hacks to hash a 64-bit identifier
> > into a 32-bit field, and deprives us of a universal identifier field for
> > an inode.
> >
> > This patchset changes the inode->i_ino field from an unsigned long to a
> > u64. This shouldn't make any material difference on 64-bit hosts, but
> > 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> > have effects on slabcache sizes and field alignment.
> >
> > The bulk of the changes are to format strings and tracepoints, since the
> > kernel itself doesn't care that much about the i_ino field. The first
> > patch changes some vfs function arguments, so check that one out
> > carefully.
> >
> > With this change, we may be able to shrink some inode structures. For
> > instance, struct nfs_inode has a fileid field that holds the 64-bit
> > inode number. With this set of changes, that field could be eliminated.
> > I'd rather leave that sort of cleanups for later just to keep this
> > simple.
> >
> > Much of this set was generated by LLM, but I attributed it to myself
> > since I consider this to be in the "menial tasks" category of LLM usage.
> >
> > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>
> Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
> i_ino and calculates either an HMAC or file meta-data hash, which is then
> signed.
>
>
Thanks Mimi, good catch.
It looks like we should just be able to change the ino field to a u64
alongside everything else. Something like this:
diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index c0ca4eedb0fe..77b6c2fa345e 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
char type, char *digest)
{
struct h_misc {
- unsigned long ino;
+ u64 ino;
__u32 generation;
uid_t uid;
gid_t gid;
That should make no material difference on 64-bit hosts. What's the
effect on 32-bit? Will they just need to remeasure everything or would
the consequences be more dire? Do we have any clue whether anyone is
using EVM in 32-bit environments?
Thanks,
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply related
* Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64
From: Mimi Zohar @ 2026-03-09 17:47 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-fsdevel, linux-kernel, linux-trace-kernel, nvdimm, fsverity,
linux-mm, netfs, linux-ext4, linux-f2fs-devel, linux-nfs,
linux-cifs, samba-technical, linux-nilfs, v9fs, linux-afs, autofs,
ceph-devel, codalist, ecryptfs, linux-mtd, jfs-discussion, ntfs3,
ocfs2-devel, devel, linux-unionfs, apparmor,
linux-security-module, linux-integrity, selinux, amd-gfx,
dri-devel, linux-media, linaro-mm-sig, netdev, linux-perf-users,
linux-fscrypt, linux-xfs, linux-hams, linux-x25, audit,
linux-bluetooth, linux-can, linux-sctp, bpf
In-Reply-To: <20260304-iino-u64-v3-0-2257ad83d372@kernel.org>
[ I/O socket time out. Trimming the To list.]
On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote:
> This version squashes all of the format-string changes and the i_ino
> type change into the same patch. This results in a giant 600+ line patch
> at the end of the series, but it does remain bisectable. Because the
> patchset was reorganized (again) some of the R-b's and A-b's have been
> dropped.
>
> The entire pile is in the "iino-u64" branch of my tree, if anyone is
> interested in testing this.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
>
> Original cover letter follows:
>
> ----------------------8<-----------------------
>
> Christian said [1] to "just do it" when I proposed this, so here we are!
>
> For historical reasons, the inode->i_ino field is an unsigned long,
> which means that it's 32 bits on 32 bit architectures. This has caused a
> number of filesystems to implement hacks to hash a 64-bit identifier
> into a 32-bit field, and deprives us of a universal identifier field for
> an inode.
>
> This patchset changes the inode->i_ino field from an unsigned long to a
> u64. This shouldn't make any material difference on 64-bit hosts, but
> 32-bit hosts will see struct inode grow by at least 4 bytes. This could
> have effects on slabcache sizes and field alignment.
>
> The bulk of the changes are to format strings and tracepoints, since the
> kernel itself doesn't care that much about the i_ino field. The first
> patch changes some vfs function arguments, so check that one out
> carefully.
>
> With this change, we may be able to shrink some inode structures. For
> instance, struct nfs_inode has a fileid field that holds the 64-bit
> inode number. With this set of changes, that field could be eliminated.
> I'd rather leave that sort of cleanups for later just to keep this
> simple.
>
> Much of this set was generated by LLM, but I attributed it to myself
> since I consider this to be in the "menial tasks" category of LLM usage.
>
> [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies the
i_ino and calculates either an HMAC or file meta-data hash, which is then
signed.
Mimi
^ permalink raw reply
* Re: [PATCH v2 v2] evm: check return values of crypto_shash functions
From: Mimi Zohar @ 2026-03-09 15:03 UTC (permalink / raw)
To: Roberto Sassu, Daniel Hodges
Cc: roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <6ce273a26b396232f3ee64a980575562e766c501.camel@huaweicloud.com>
On Thu, 2026-02-19 at 10:26 +0100, Roberto Sassu wrote:
> On Thu, 2026-02-05 at 21:42 -0500, Daniel Hodges wrote:
> > The crypto_shash_update() and crypto_shash_final() functions can fail
> > and return error codes, but their return values were not being checked
> > in several places in security/integrity/evm/evm_crypto.c:
> >
> > - hmac_add_misc() ignored returns from crypto_shash_update() and
> > crypto_shash_final()
> > - evm_calc_hmac_or_hash() ignored returns from crypto_shash_update()
> > - evm_init_hmac() ignored returns from crypto_shash_update()
> >
> > If these hash operations fail silently, the resulting HMAC could be
> > invalid or incomplete, which could weaken the integrity verification
> > security that EVM provides.
> >
> > This patch converts hmac_add_misc() from void to int return type and
> > adds proper error checking and propagation for all crypto_shash_*
> > function calls. All callers are updated to handle the new return values.
> > Additionally, error messages are logged when cryptographic operations
> > fail to provide visibility into the failure rather than silently
> > returning error codes.
> >
> > Fixes: 66dbc325afce ("evm: re-release")
> > Signed-off-by: Daniel Hodges <git@danielhodges.dev>
>
> After fixing the minor issue below:
>
> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
Thanks Daniel, Roberto. Daniel there are a couple of places where the line
length is greater than 80. To see them, add "--max-line-length=80" to
scripts/checkpatch.pl. I'd appreciate your fixing them. Otherwise, the patch
looks good.
Thanks,
Mimi
^ permalink raw reply
* Re: [PATCH] ima: check return value of crypto_shash_final() in boot aggregate
From: Mimi Zohar @ 2026-03-09 15:03 UTC (permalink / raw)
To: Daniel Hodges, Roberto Sassu, Dmitry Kasatkin
Cc: Eric Snowberg, Paul Moore, James Morris, Serge E . Hallyn,
linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <20260201024015.2862236-1-hodgesd@meta.com>
On Sat, 2026-01-31 at 18:40 -0800, Daniel Hodges wrote:
> The return value of crypto_shash_final() is not checked in
> ima_calc_boot_aggregate_tfm(). If the hash finalization fails, the
> function returns success and a corrupted boot aggregate digest could
> be used for IMA measurements.
>
> Capture the return value and propagate any error to the caller.
>
> Fixes: 76bb28f6126f ("ima: use new crypto_shash API instead of old crypto_hash")
> Signed-off-by: Daniel Hodges <hodgesd@meta.com>
Thanks, Daniel. The patch is now queueud.
Mimi
^ permalink raw reply
* Re: [PATCH] integrity: avoid using __weak functions
From: Mimi Zohar @ 2026-03-09 1:01 UTC (permalink / raw)
To: Nathan Chancellor, Arnd Bergmann
Cc: Madhavan Srinivasan, Michael Ellerman, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Arnd Bergmann, Roberto Sassu,
Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn,
Jarkko Sakkinen, Ard Biesheuvel, Coiby Xu, Nicholas Piggin,
Christophe Leroy (CS GROUP), Christian Borntraeger, Sven Schnelle,
Eric Snowberg, Nick Desaulniers, Bill Wendling, Justin Stitt,
Andrew Donnellan, linuxppc-dev, linux-kernel, linux-s390,
linux-arch, linux-integrity, linux-security-module, keyrings,
llvm
In-Reply-To: <20260306225648.GC2746259@ax162>
On Fri, 2026-03-06 at 15:56 -0700, Nathan Chancellor wrote:
> On Fri, Mar 06, 2026 at 04:03:24PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > The security/integrity/secure_boot.c file containing only a __weak function
> > leads to a build failure with clang:
> >
> > Cannot find symbol for section 2: .text.
> > security/integrity/secure_boot.o: failed
> >
> > Moving the function into another file that has at least one non-__weak
> > symbol would solve this, but this is always fragile.
> >
> > Avoid __weak definitions entirely and instead move the stub helper into
> > an asm-generic header that gets used by default on architectures that
> > do not provide their own version. This is consistent with how a lot
> > of other architecture specific functionality works, and is more reliable.
> >
> > Fixes: a0f87ede3bf4 ("integrity: Make arch_ima_get_secureboot integrity-wide")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > This is a larger change than I had hoped for.
> >
> > If you prefer a different way to address the build failure, please
> > treat this as a Reported-by when you apply your own fix
> > ---
> > arch/powerpc/include/asm/secure_boot.h | 6 +++
> > arch/powerpc/kernel/secure_boot.c | 1 -
> > arch/s390/include/asm/secure_boot.h | 9 +++++
> > include/asm-generic/Kbuild | 1 +
> > include/asm-generic/secure_boot.h | 37 +++++++++++++++++++
> > include/linux/secure_boot.h | 8 +---
> > security/integrity/Makefile | 2 +-
> > .../integrity/platform_certs/load_powerpc.c | 2 +-
> > security/integrity/secure_boot.c | 16 --------
> > 9 files changed, 56 insertions(+), 26 deletions(-)
> > create mode 100644 arch/s390/include/asm/secure_boot.h
> > create mode 100644 include/asm-generic/secure_boot.h
> > delete mode 100644 security/integrity/secure_boot.c
>
> Thanks, I noticed this as well. The version I came up with and have been
> locally testing is the following, which is a little bit more compact.
Thanks Arnd, Nathan. LGTM. Nathan, could you send a patch with a proper patch
description.
Mimi
>
> arch/Kconfig | 3 +++
> arch/powerpc/Kconfig | 1 +
> arch/s390/Kconfig | 1 +
> arch/s390/kernel/ipl.c | 10 +++++-----
> include/linux/secure_boot.h | 4 ++++
> security/integrity/Makefile | 2 +-
> security/integrity/secure_boot.c | 16 ----------------
> 7 files changed, 15 insertions(+), 22 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 102ddbd4298e..a6d1c8cc1d64 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1841,4 +1841,7 @@ config ARCH_WANTS_PRE_LINK_VMLINUX
> config ARCH_HAS_CPU_ATTACK_VECTORS
> bool
>
> +config HAVE_ARCH_GET_SECUREBOOT
> + def_bool EFI
> +
> endmenu
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c28776660246..e76d6cf0c403 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -1062,6 +1062,7 @@ config PPC_SECURE_BOOT
> depends on IMA_ARCH_POLICY
> imply IMA_SECURE_AND_OR_TRUSTED_BOOT
> select PSERIES_PLPKS if PPC_PSERIES
> + select HAVE_ARCH_GET_SECUREBOOT
> help
> Systems with firmware secure boot enabled need to define security
> policies to extend secure boot to the OS. This config allows a user
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 24695ea29d5b..76f191dd208b 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -181,6 +181,7 @@ config S390
> select GENERIC_IOREMAP if PCI
> select HAVE_ALIGNED_STRUCT_PAGE
> select HAVE_ARCH_AUDITSYSCALL
> + select HAVE_ARCH_GET_SECUREBOOT
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_JUMP_LABEL_RELATIVE
> select HAVE_ARCH_KASAN
> diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
> index 2d01a1713938..3c346b02ceb9 100644
> --- a/arch/s390/kernel/ipl.c
> +++ b/arch/s390/kernel/ipl.c
> @@ -2388,6 +2388,11 @@ void __no_stack_protector s390_reset_system(void)
> diag_amode31_ops.diag308_reset();
> }
>
> +bool arch_get_secureboot(void)
> +{
> + return ipl_secure_flag;
> +}
> +
> #ifdef CONFIG_KEXEC_FILE
>
> int ipl_report_add_component(struct ipl_report *report, struct kexec_buf *kbuf,
> @@ -2505,11 +2510,6 @@ void *ipl_report_finish(struct ipl_report *report)
> return buf;
> }
>
> -bool arch_get_secureboot(void)
> -{
> - return ipl_secure_flag;
> -}
> -
> int ipl_report_free(struct ipl_report *report)
> {
> struct ipl_report_component *comp, *ncomp;
> diff --git a/include/linux/secure_boot.h b/include/linux/secure_boot.h
> index 3ded3f03655c..d17e92351567 100644
> --- a/include/linux/secure_boot.h
> +++ b/include/linux/secure_boot.h
> @@ -10,10 +10,14 @@
>
> #include <linux/types.h>
>
> +#ifdef CONFIG_HAVE_ARCH_GET_SECUREBOOT
> /*
> * Returns true if the platform secure boot is enabled.
> * Returns false if disabled or not supported.
> */
> bool arch_get_secureboot(void);
> +#else
> +static inline bool arch_get_secureboot(void) { return false; }
> +#endif
>
> #endif /* _LINUX_SECURE_BOOT_H */
> diff --git a/security/integrity/Makefile b/security/integrity/Makefile
> index 548665e2b702..45dfdedbdad4 100644
> --- a/security/integrity/Makefile
> +++ b/security/integrity/Makefile
> @@ -5,7 +5,7 @@
>
> obj-$(CONFIG_INTEGRITY) += integrity.o
>
> -integrity-y := iint.o secure_boot.o
> +integrity-y := iint.o
> integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
> integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
> integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
> diff --git a/security/integrity/secure_boot.c b/security/integrity/secure_boot.c
> deleted file mode 100644
> index fc2693c286f8..000000000000
> --- a/security/integrity/secure_boot.c
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/*
> - * Copyright (C) 2026 Red Hat, Inc. All Rights Reserved.
> - *
> - * Author: Coiby Xu <coxu@redhat.com>
> - */
> -#include <linux/secure_boot.h>
> -
> -/*
> - * Default weak implementation.
> - * Architectures that support secure boot must override this.
> - */
> -__weak bool arch_get_secureboot(void)
> -{
> - return false;
> -}
^ permalink raw reply
* Re: [PATCH] integrity: avoid using __weak functions
From: Arnd Bergmann @ 2026-03-06 23:28 UTC (permalink / raw)
To: Nathan Chancellor, Arnd Bergmann
Cc: Madhavan Srinivasan, Michael Ellerman, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Mimi Zohar, Roberto Sassu,
Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn,
Jarkko Sakkinen, Ard Biesheuvel, Coiby Xu, Nicholas Piggin,
Christophe Leroy, Christian Borntraeger, Sven Schnelle,
Eric Snowberg, Nick Desaulniers, Bill Wendling, Justin Stitt,
Andrew Donnellan, linuxppc-dev, linux-kernel, linux-s390,
Linux-Arch, linux-integrity, linux-security-module, keyrings,
llvm
In-Reply-To: <20260306225648.GC2746259@ax162>
On Fri, Mar 6, 2026, at 23:56, Nathan Chancellor wrote:
> On Fri, Mar 06, 2026 at 04:03:24PM +0100, Arnd Bergmann wrote:
>
> Thanks, I noticed this as well. The version I came up with and have been
> locally testing is the following, which is a little bit more compact.
>
> arch/Kconfig | 3 +++
> arch/powerpc/Kconfig | 1 +
> arch/s390/Kconfig | 1 +
> arch/s390/kernel/ipl.c | 10 +++++-----
> include/linux/secure_boot.h | 4 ++++
> security/integrity/Makefile | 2 +-
> security/integrity/secure_boot.c | 16 ----------------
> 7 files changed, 15 insertions(+), 22 deletions(-)
>
Right, your version looks good to me as well.
Arnd
^ permalink raw reply
* Re: [PATCH] integrity: avoid using __weak functions
From: Nathan Chancellor @ 2026-03-06 22:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Madhavan Srinivasan, Michael Ellerman, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Arnd Bergmann, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Paul Moore, James Morris,
Serge E. Hallyn, Jarkko Sakkinen, Ard Biesheuvel, Coiby Xu,
Nicholas Piggin, Christophe Leroy (CS GROUP),
Christian Borntraeger, Sven Schnelle, Eric Snowberg,
Nick Desaulniers, Bill Wendling, Justin Stitt, Andrew Donnellan,
linuxppc-dev, linux-kernel, linux-s390, linux-arch,
linux-integrity, linux-security-module, keyrings, llvm
In-Reply-To: <20260306150421.270124-1-arnd@kernel.org>
On Fri, Mar 06, 2026 at 04:03:24PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The security/integrity/secure_boot.c file containing only a __weak function
> leads to a build failure with clang:
>
> Cannot find symbol for section 2: .text.
> security/integrity/secure_boot.o: failed
>
> Moving the function into another file that has at least one non-__weak
> symbol would solve this, but this is always fragile.
>
> Avoid __weak definitions entirely and instead move the stub helper into
> an asm-generic header that gets used by default on architectures that
> do not provide their own version. This is consistent with how a lot
> of other architecture specific functionality works, and is more reliable.
>
> Fixes: a0f87ede3bf4 ("integrity: Make arch_ima_get_secureboot integrity-wide")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This is a larger change than I had hoped for.
>
> If you prefer a different way to address the build failure, please
> treat this as a Reported-by when you apply your own fix
> ---
> arch/powerpc/include/asm/secure_boot.h | 6 +++
> arch/powerpc/kernel/secure_boot.c | 1 -
> arch/s390/include/asm/secure_boot.h | 9 +++++
> include/asm-generic/Kbuild | 1 +
> include/asm-generic/secure_boot.h | 37 +++++++++++++++++++
> include/linux/secure_boot.h | 8 +---
> security/integrity/Makefile | 2 +-
> .../integrity/platform_certs/load_powerpc.c | 2 +-
> security/integrity/secure_boot.c | 16 --------
> 9 files changed, 56 insertions(+), 26 deletions(-)
> create mode 100644 arch/s390/include/asm/secure_boot.h
> create mode 100644 include/asm-generic/secure_boot.h
> delete mode 100644 security/integrity/secure_boot.c
Thanks, I noticed this as well. The version I came up with and have been
locally testing is the following, which is a little bit more compact.
arch/Kconfig | 3 +++
arch/powerpc/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/s390/kernel/ipl.c | 10 +++++-----
include/linux/secure_boot.h | 4 ++++
security/integrity/Makefile | 2 +-
security/integrity/secure_boot.c | 16 ----------------
7 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 102ddbd4298e..a6d1c8cc1d64 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1841,4 +1841,7 @@ config ARCH_WANTS_PRE_LINK_VMLINUX
config ARCH_HAS_CPU_ATTACK_VECTORS
bool
+config HAVE_ARCH_GET_SECUREBOOT
+ def_bool EFI
+
endmenu
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c28776660246..e76d6cf0c403 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1062,6 +1062,7 @@ config PPC_SECURE_BOOT
depends on IMA_ARCH_POLICY
imply IMA_SECURE_AND_OR_TRUSTED_BOOT
select PSERIES_PLPKS if PPC_PSERIES
+ select HAVE_ARCH_GET_SECUREBOOT
help
Systems with firmware secure boot enabled need to define security
policies to extend secure boot to the OS. This config allows a user
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 24695ea29d5b..76f191dd208b 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -181,6 +181,7 @@ config S390
select GENERIC_IOREMAP if PCI
select HAVE_ALIGNED_STRUCT_PAGE
select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_GET_SECUREBOOT
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN
diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index 2d01a1713938..3c346b02ceb9 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -2388,6 +2388,11 @@ void __no_stack_protector s390_reset_system(void)
diag_amode31_ops.diag308_reset();
}
+bool arch_get_secureboot(void)
+{
+ return ipl_secure_flag;
+}
+
#ifdef CONFIG_KEXEC_FILE
int ipl_report_add_component(struct ipl_report *report, struct kexec_buf *kbuf,
@@ -2505,11 +2510,6 @@ void *ipl_report_finish(struct ipl_report *report)
return buf;
}
-bool arch_get_secureboot(void)
-{
- return ipl_secure_flag;
-}
-
int ipl_report_free(struct ipl_report *report)
{
struct ipl_report_component *comp, *ncomp;
diff --git a/include/linux/secure_boot.h b/include/linux/secure_boot.h
index 3ded3f03655c..d17e92351567 100644
--- a/include/linux/secure_boot.h
+++ b/include/linux/secure_boot.h
@@ -10,10 +10,14 @@
#include <linux/types.h>
+#ifdef CONFIG_HAVE_ARCH_GET_SECUREBOOT
/*
* Returns true if the platform secure boot is enabled.
* Returns false if disabled or not supported.
*/
bool arch_get_secureboot(void);
+#else
+static inline bool arch_get_secureboot(void) { return false; }
+#endif
#endif /* _LINUX_SECURE_BOOT_H */
diff --git a/security/integrity/Makefile b/security/integrity/Makefile
index 548665e2b702..45dfdedbdad4 100644
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -5,7 +5,7 @@
obj-$(CONFIG_INTEGRITY) += integrity.o
-integrity-y := iint.o secure_boot.o
+integrity-y := iint.o
integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
diff --git a/security/integrity/secure_boot.c b/security/integrity/secure_boot.c
deleted file mode 100644
index fc2693c286f8..000000000000
--- a/security/integrity/secure_boot.c
+++ /dev/null
@@ -1,16 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2026 Red Hat, Inc. All Rights Reserved.
- *
- * Author: Coiby Xu <coxu@redhat.com>
- */
-#include <linux/secure_boot.h>
-
-/*
- * Default weak implementation.
- * Architectures that support secure boot must override this.
- */
-__weak bool arch_get_secureboot(void)
-{
- return false;
-}
^ permalink raw reply related
* Re: [PATCH 1/1] s390/ipl: Fix missing arch_get_secureboot() prototype warning
From: kernel test robot @ 2026-03-06 21:16 UTC (permalink / raw)
To: Vasily Gorbik, Mimi Zohar
Cc: llvm, oe-kbuild-all, linux-integrity, Heiko Carstens,
Alexander Egorenkov, Ard Biesheuvel, Dave Hansen, Coiby Xu,
Roberto Sassu, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Thomas Gleixner,
Ingo Molnar, Borislav Petkov,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, Jarkko Sakkinen, open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)
In-Reply-To: <p01-01.g9ec0a81d34d1.ttbfdx5@ub.hpns>
Hi Vasily,
kernel test robot noticed the following build errors:
[auto build test ERROR on v7.0-rc2]
[also build test ERROR on linus/master]
[cannot apply to next-20260306]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Vasily-Gorbik/s390-ipl-Fix-missing-arch_get_secureboot-prototype-warning/20260305-230453
base: v7.0-rc2
patch link: https://lore.kernel.org/r/p01-01.g9ec0a81d34d1.ttbfdx5%40ub.hpns
patch subject: [PATCH 1/1] s390/ipl: Fix missing arch_get_secureboot() prototype warning
config: s390-allmodconfig (https://download.01.org/0day-ci/archive/20260307/202603070500.3pafeTNF-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260307/202603070500.3pafeTNF-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603070500.3pafeTNF-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/s390/kernel/ipl.c:24:10: fatal error: 'linux/secure_boot.h' file not found
24 | #include <linux/secure_boot.h>
| ^~~~~~~~~~~~~~~~~~~~~
1 error generated.
vim +24 arch/s390/kernel/ipl.c
> 24 #include <linux/secure_boot.h>
25 #include <asm/asm-extable.h>
26 #include <asm/machine.h>
27 #include <asm/diag.h>
28 #include <asm/ipl.h>
29 #include <asm/smp.h>
30 #include <asm/setup.h>
31 #include <asm/cpcmd.h>
32 #include <asm/ebcdic.h>
33 #include <asm/sclp.h>
34 #include <asm/checksum.h>
35 #include <asm/debug.h>
36 #include <asm/abs_lowcore.h>
37 #include <asm/os_info.h>
38 #include <asm/sections.h>
39 #include <asm/boot_data.h>
40 #include "entry.h"
41
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] ima: detect file change code cleanup
From: Frederick Lawler @ 2026-03-06 19:58 UTC (permalink / raw)
To: Mimi Zohar; +Cc: linux-integrity, Jeff Layton, Roberto Sassu
In-Reply-To: <20260306190141.309937-1-zohar@linux.ibm.com>
Hi Mimi,
On Fri, Mar 06, 2026 at 02:01:40PM -0500, Mimi Zohar wrote:
> Functionally no change, just simplify the ima_detect_file_change() code.
>
> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> ---
> @Fred, looking to merge with commit 0824f861605d ("ima: fallback to using
> i_version to detect file change")
>
> security/integrity/ima/ima_main.c | 19 +++++++------------
> 1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 6c49afa8dcc0..5cea53fc36df 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -194,18 +194,13 @@ static bool ima_detect_file_change(struct ima_iint_cache *iint,
> result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE,
> AT_STATX_SYNC_AS_STAT);
>
> - if (!result && stat.result_mask & STATX_CHANGE_COOKIE &&
> - stat.change_cookie != iint->real_inode.version)
> - return true;
> - else if (!(stat.result_mask & STATX_CHANGE_COOKIE) &&
> - IS_I_VERSION(inode) &&
> - !(inode_eq_iversion(inode, iint->real_inode.version)))
> - return true;
> - else if (!(stat.result_mask & STATX_CHANGE_COOKIE) &&
> - !(IS_I_VERSION(inode)))
> - return true;
> -
> - return false;
> + if (!result && stat.result_mask & STATX_CHANGE_COOKIE)
> + return stat.change_cookie != iint->real_inode.version;
> +
> + if (IS_I_VERSION(inode))
> + return !inode_eq_iversion(inode, iint->real_inode.version);
> +
> + return true;
> }
>
> static void ima_check_last_writer(struct ima_iint_cache *iint,
> --
> 2.53.0
>
Refactor looks good to me.
Reviewed-by: Frederick Lawler <fred@cloudflare.com>
Best,
Fred
^ permalink raw reply
* [PATCH] ima: detect file change code cleanup
From: Mimi Zohar @ 2026-03-06 19:01 UTC (permalink / raw)
To: linux-integrity; +Cc: Mimi Zohar, Frederick Lawler, Jeff Layton, Roberto Sassu
Functionally no change, just simplify the ima_detect_file_change() code.
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
---
@Fred, looking to merge with commit 0824f861605d ("ima: fallback to using
i_version to detect file change")
security/integrity/ima/ima_main.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 6c49afa8dcc0..5cea53fc36df 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -194,18 +194,13 @@ static bool ima_detect_file_change(struct ima_iint_cache *iint,
result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE,
AT_STATX_SYNC_AS_STAT);
- if (!result && stat.result_mask & STATX_CHANGE_COOKIE &&
- stat.change_cookie != iint->real_inode.version)
- return true;
- else if (!(stat.result_mask & STATX_CHANGE_COOKIE) &&
- IS_I_VERSION(inode) &&
- !(inode_eq_iversion(inode, iint->real_inode.version)))
- return true;
- else if (!(stat.result_mask & STATX_CHANGE_COOKIE) &&
- !(IS_I_VERSION(inode)))
- return true;
-
- return false;
+ if (!result && stat.result_mask & STATX_CHANGE_COOKIE)
+ return stat.change_cookie != iint->real_inode.version;
+
+ if (IS_I_VERSION(inode))
+ return !inode_eq_iversion(inode, iint->real_inode.version);
+
+ return true;
}
static void ima_check_last_writer(struct ima_iint_cache *iint,
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox