On Sat, Dec 23, 2023 at 5:49 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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. -- paul-moore.com
