On Sat, Dec 23, 2023 at 5:49 AM Tetsuo Handa penguin-kernel@i-love.sakura.ne.jp wrote:
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'm not worried about @arg, I'm worried about @cmd, the second parameter to the syscall. I was looking at the manpage and it is specified as an unsigned long, which would be a size mismatch on a 64-bit system, although now that I'm reading further into the manpage I see that the command is specified as a 32-bit value so an int shouldn't be a problem. I'm guessing the unsigned long type persists from the days before 64-bit systems.
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.
Great, thank you.