Thread (11 messages) 11 messages, 3 authors, 2024-03-14

Re: [PATCH v3] LSM: use 32 bit compatible data types in LSM syscalls.

From: Paul Moore <paul@paul-moore.com>
Date: 2024-03-14 18:18:39
Also in: linux-security-module, lkml

On Thu, Mar 14, 2024 at 2:01 PM Dmitry V. Levin [off-list ref] wrote:
On Thu, Mar 14, 2024 at 11:30:53AM -0400, Paul Moore wrote:
quoted
On Wed, Mar 13, 2024 at 4:07 PM Paul Moore [off-list ref] wrote:
quoted
On Mar 13, 2024 Casey Schaufler [off-list ref] wrote:
quoted
LSM: use 32 bit compatible data types in LSM syscalls.

Change the size parameters in lsm_list_modules(), lsm_set_self_attr()
and lsm_get_self_attr() from size_t to u32. This avoids the need to
have different interfaces for 32 and 64 bit systems.

Cc: stable@vger.kernel.org
Fixes: a04a1198088a: ("LSM: syscalls for current process attributes")
Fixes: ad4aff9ec25f: ("LSM: Create lsm_list_modules system call")
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Reported-and-reviewed-by: Dmitry V. Levin [off-list ref]
---
 include/linux/lsm_hook_defs.h                        |  4 ++--
 include/linux/security.h                             |  8 ++++----
 security/apparmor/lsm.c                              |  4 ++--
 security/lsm_syscalls.c                              | 10 +++++-----
 security/security.c                                  | 12 ++++++------
 security/selinux/hooks.c                             |  4 ++--
 security/smack/smack_lsm.c                           |  4 ++--
 tools/testing/selftests/lsm/common.h                 |  6 +++---
 tools/testing/selftests/lsm/lsm_get_self_attr_test.c | 10 +++++-----
 tools/testing/selftests/lsm/lsm_list_modules_test.c  |  8 ++++----
 tools/testing/selftests/lsm/lsm_set_self_attr_test.c |  6 +++---
 11 files changed, 38 insertions(+), 38 deletions(-)
Okay, this looks better, I'm going to merge this into lsm/stable-6.9
and put it through the usual automated testing as well as a kselftest
run to make sure everything there is still okay.  Assuming all goes
well and no one raises any objections, I'll likely send this up to
Linus tomorrow.
I had to squash the code snippet below into the patch to address a
build problem identified by the kernel build robot.  I'm going to keep
Casey's sign-off and Dmitry's reported-reviewed tag as I feel this
change is minor, but if anyone has any objections please let me know
soon.

[NOTE: cut-n-paste'd into email, likely whitespace damage, but you get the idea]
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 77eb9b0e7685..e619ac10cd23 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -960,10 +960,10 @@ asmlinkage long sys_cachestat(unsigned int fd,
               struct cachestat __user *cstat, unsigned int flags);
asmlinkage long sys_map_shadow_stack(unsigned long addr, unsigned long size, un
signed int flags);
asmlinkage long sys_lsm_get_self_attr(unsigned int attr, struct lsm_ctx *ctx,
-                                     size_t *size, __u32 flags);
+                                     u32 *size, u32 flags);
asmlinkage long sys_lsm_set_self_attr(unsigned int attr, struct lsm_ctx *ctx,
-                                     size_t size, __u32 flags);
-asmlinkage long sys_lsm_list_modules(u64 *ids, size_t *size, u32 flags);
+                                     u32 size, u32 flags);
+asmlinkage long sys_lsm_list_modules(u64 *ids, u32 *size, u32 flags);
Fine with me, thanks.

btw, with the change above, u32 will become about twice more popular
in include/linux/syscalls.h than __u32.
I was looking at that when I was putting the patch together this
morning, trying to decide which was the "correct" choice between 'u32'
and '__u32' and wasn't able to find a good explanation of which is the
"right" option in this file.  Ultimately I went with 'u32' as I tend
to follow some old guidance of: '__u32' for userspace headers, 'u32'
for kernel headers.

If it should be the other way, please let me know.  I just want to
keep it consistent across the LSM syscalls.

-- 
paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help