Skip to content

Commit bef5b11

Browse files
jtlaytonbrauner
authored andcommitted
EVM: add comment describing why ino field is still unsigned long
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 require EVM resigning 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. Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://patch.msgid.link/20260316-iino-u64-v3-1-d1076b8f7a20@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
1 parent 9840bb6 commit bef5b11

1 file changed

Lines changed: 6 additions & 0 deletions

File tree

security/integrity/evm/evm_crypto.c

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -144,6 +144,12 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
144144
char type, char *digest)
145145
{
146146
struct h_misc {
147+
/*
148+
* Although inode->i_ino is now u64, this field remains
149+
* unsigned long to allow existing HMAC and signatures from
150+
* 32-bit hosts to continue working when i_ino hasn't changed
151+
* and fits in a u32.
152+
*/
147153
unsigned long ino;
148154
__u32 generation;
149155
uid_t uid;

0 commit comments

Comments
 (0)