Q: arch/mips && __secure_computing(sd) with sd != NULL

From include/linux/seccomp.h

	#ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
	extern int __secure_computing(const struct seccomp_data *sd);

in this case sd can be NULL, and only arch/mips/kernel/ptrace.c uses sd != NULL

	#else
	static inline int __secure_computing(const struct seccomp_data *sd)
	{
		secure_computing_strict(sd->nr);
		return 0;
	}

in this case __secure_computing(NULL) will crash. This looks confusing. And unnecessary.

Now lets look at arch/mips/kernel/ptrace.c:syscall_trace_enter()

	#ifdef CONFIG_SECCOMP
		if (unlikely(test_thread_flag(TIF_SECCOMP))) {
			int ret, i;
			struct seccomp_data sd;
			unsigned long args[6];

			sd.nr = current_thread_info()->syscall;
			sd.arch = syscall_get_arch(current);
			syscall_get_arguments(current, regs, args);
			for (i = 0; i < 6; i++)
				sd.args[i] = args[i];
			sd.instruction_pointer = KSTK_EIP(current);

			ret = __secure_computing(&sd);
			if (ret == -1)
				return ret;
		}
	#endif

Why? arch/mips/Kconfig selects HAVE_ARCH_SECCOMP_FILTER so it can just do

	#ifdef CONFIG_SECCOMP
		if (unlikely(test_thread_flag(TIF_SECCOMP))) {
			int ret = __secure_computing(NULL);
			if (ret == -1)
				return ret;
		}
	#endif

and rely on populate_seccomp_data() and sd == NULL checks in __secure_computing() path ?

And given that arch/mips doesn't define CONFIG_GENERIC_ENTRY it can even do

	int ret = secure_computing();
	if (ret == -1)
		return ret;

Did I miss something?

Note that if we change arch/mips we can do more cleanups, in particular __secure_computing(sd) no longer needs the argument.

Oleg.

Yeah, seems like reasonable clean-up. The argument is a leftover from x86 having sd pre-populated under certain paths.

Kees Cook