On 2023/12/23 10:23, Paul Moore wrote:
/* RED-PEN how should LSM module know it's handling 32bit? */error = security_file_ioctl(f.file, cmd, arg);
error = security_file_ioctl_compat(f.file, cmd, arg); if (error) goto out;This is interesting ... if you look at the normal ioctl() syscall definition in the kernel you see 'ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)' and if you look at the compat definition you see 'ioctl(unsigned int fd, unsigned int cmd, compat_ulong_t arg)'. I was expecting the second parameter, @cmd, to be a long type in the normal definition, but it is an int type in both cases. It looks like it has been that way long enough that it is correct, but I'm a little lost ...
Since @arg might be a pointer to some struct, @arg needs to use a long type. But @cmd can remain 32bits for both 32bits/64bits kernels because @cmd is not a pointer, can't it?
I agree that it looks like Smack and TOMOYO should be fine, but I would like to hear from Casey and Tetsuo to confirm.
Fine for TOMOYO part, for TOMOYO treats @cmd as an integer.