Skip to contentSkip to conversation

seccomp: Use -1 marker for end of mode 1 syscall list

PATCH In review Kees Cook 2 participants 4 messages Jun 19, 2020

Subsystems (3)
MIPS Generic include/asm header files Secure computing
lore
Share & tools
lore

Kees Cook

author
#0 lore raw

PATCH 1/1 seccomp: Use -1 marker for end of mode 1 syscall list

The terminator for the mode 1 syscalls list was a 0, but that could be a valid syscall number (e.g. x86_64 __NR_read). By luck, __NR_read was listed first and the loop construct would not test it, so there was no bug. However, this is fragile. Replace the terminator with -1 instead, and make the variable name for mode 1 syscall lists more descriptive.

Signed-off-by Kees Cook <[email protected]>

---
I'll be putting this into my for-next/seccomp tree. I would love a MIPS ack, if someone's got a moment to double-check this. :)

---
 arch/mips/include/asm/seccomp.h |  4 ++--
 include/asm-generic/seccomp.h   |  2 +-
 kernel/seccomp.c                | 10 +++++-----
 3 files changed, 8 insertions(+), 8 deletions(-)
arch/mips/include/asm/seccomp.h +2 -2
index e383d7e27b93..aa809589a181 100644
@@ -9,12 +9,12 @@ static inline const int *get_compat_mode1_syscalls(void)
 	static const int syscalls_O32[] = {
 		__NR_O32_Linux + 3, __NR_O32_Linux + 4,
 		__NR_O32_Linux + 1, __NR_O32_Linux + 193,
-		0, /* null terminated */
+		-1, /* negative terminated */
 	};
 	static const int syscalls_N32[] = {
 		__NR_N32_Linux + 0, __NR_N32_Linux + 1,
 		__NR_N32_Linux + 58, __NR_N32_Linux + 211,
-		0, /* null terminated */
+		-1, /* negative terminated */
 	};
 
 	if (IS_ENABLED(CONFIG_MIPS32_O32) && test_thread_flag(TIF_32BIT_REGS))
include/asm-generic/seccomp.h +1 -1
index 1321ac7821d7..6b6f42bc58f9 100644
@@ -33,7 +33,7 @@ static inline const int *get_compat_mode1_syscalls(void)
 	static const int mode1_syscalls_32[] = {
 		__NR_seccomp_read_32, __NR_seccomp_write_32,
 		__NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
-		0, /* null terminated */
+		-1, /* negative terminated */
 	};
 	return mode1_syscalls_32;
 }
kernel/seccomp.c +5 -5
index 0ed57e8c49d0..866a432cd746 100644
@@ -742,20 +742,20 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action,
  */
 static const int mode1_syscalls[] = {
 	__NR_seccomp_read, __NR_seccomp_write, __NR_seccomp_exit, __NR_seccomp_sigreturn,
-	0, /* null terminated */
+	-1, /* negative terminated */
 };
 
 static void __secure_computing_strict(int this_syscall)
 {
-	const int *syscall_whitelist = mode1_syscalls;
+	const int *allowed_syscalls = mode1_syscalls;
 #ifdef CONFIG_COMPAT
 	if (in_compat_syscall())
-		syscall_whitelist = get_compat_mode1_syscalls();
+		allowed_syscalls = get_compat_mode1_syscalls();
 #endif
 	do {
-		if (*syscall_whitelist == this_syscall)
+		if (*allowed_syscalls == this_syscall)
 			return;
-	} while (*++syscall_whitelist);
+	} while (*++allowed_syscalls != -1);
 
 #ifdef SECCOMP_DEBUG
 	dump_stack();
Signature · 5 lines
2.25.1


-- 
Kees Cook
#1 lore raw
Quoted 6 lines · Kees Cook

The terminator for the mode 1 syscalls list was a 0, but that could be a valid syscall number (e.g. x86_64 __NR_read). By luck, __NR_read was listed first and the loop construct would not test it, so there was no bug. However, this is fragile. Replace the terminator with -1 instead, and make the variable name for mode 1 syscall lists more descriptive.

Could the architecture instead supply the length of the list?

--Andy

author
#2 lore raw
Quoted 9 lines · Andy Lutomirski
Quoted 6 lines · Kees Cook

The terminator for the mode 1 syscalls list was a 0, but that could be a valid syscall number (e.g. x86_64 __NR_read). By luck, __NR_read was listed first and the loop construct would not test it, so there was no bug. However, this is fragile. Replace the terminator with -1 instead, and make the variable name for mode 1 syscall lists more descriptive.

Could the architecture instead supply the length of the list?

It could, but I didn't like the way the plumbing for that looked.

Signature · 1 line
Kees Cook
#3 lore raw
Quoted 10 lines · Kees Cook
Quoted 8 lines · Andy Lutomirski
Quoted 6 lines · Kees Cook

The terminator for the mode 1 syscalls list was a 0, but that could be a valid syscall number (e.g. x86_64 __NR_read). By luck, __NR_read was listed first and the loop construct would not test it, so there was no bug. However, this is fragile. Replace the terminator with -1 instead, and make the variable name for mode 1 syscall lists more descriptive.

Quoted 3 lines
Quoted 1 line

Could the architecture instead supply the length of the list?

It could, but I didn't like the way the plumbing for that looked.

Fair enough.

Quoted 3 lines

--
Kees Cook