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 <[email protected]> > Signed-off-by: Jeff Layton <[email protected]> > --- > 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;
