On 3/12/2024 6:25 AM, Paul Moore wrote: > On Tue, Mar 12, 2024 at 6:16 AM Dmitry V. Levin <ldv@xxxxxxxxx> wrote: >> On Tue, Sep 12, 2023 at 01:56:50PM -0700, Casey Schaufler wrote: >> [...] >>> --- a/security/lsm_syscalls.c >>> +++ b/security/lsm_syscalls.c >>> @@ -55,3 +55,42 @@ SYSCALL_DEFINE4(lsm_get_self_attr, unsigned int, attr, struct lsm_ctx __user *, >>> { >>> return security_getselfattr(attr, ctx, size, flags); >>> } >>> + >>> +/** >>> + * sys_lsm_list_modules - Return a list of the active security modules >>> + * @ids: the LSM module ids >>> + * @size: pointer to size of @ids, updated on return >>> + * @flags: reserved for future use, must be zero >>> + * >>> + * Returns a list of the active LSM ids. On success this function >>> + * returns the number of @ids array elements. This value may be zero >>> + * if there are no LSMs active. If @size is insufficient to contain >>> + * the return data -E2BIG is returned and @size is set to the minimum >>> + * required size. In all other cases a negative value indicating the >>> + * error is returned. >>> + */ >>> +SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, size_t __user *, size, >>> + u32, flags) >> I'm sorry but the size of userspace size_t is different from the kernel one >> on 32-bit compat architectures. > D'oh, yes, thanks for pointing that out. It would have been nice to > have caught that before v6.8 was released, but I guess it's better > than later. > >> Looks like there has to be a COMPAT_SYSCALL_DEFINE3(lsm_list_modules, ...) >> now. Other two added lsm syscalls also have this issue. > Considering that Linux v6.8, and by extension these syscalls, are only > a few days old, I think I'd rather see us just modify the syscalls and > avoid the compat baggage. I'm going to be shocked if anyone has > shifted to using the new syscalls yet, and even if they have (!!), > moving from a "size_t" type to a "u64" should be mostly transparent > for the majority of native 64-bit systems. Those running the absolute > latest kernels on 32-bit systems with custom or bleeding edge > userspace *may* see a slight hiccup, but I think that user count is in > the single digits, if not zero. > > Let's fix this quickly with /size_t/u64/ in v6.8.1 and avoid the > compat shim if we can. > > Casey, do you have time to put together a patch for this (you should > fix the call chains below the syscalls too)? If not, please let me > know and I'll get a patch out ASAP. Grumble. Yes, I'll get right on it. > > Thanks all. >