* Q: arch/mips && __secure_computing(sd) with sd != NULL
@ 2025-01-18 16:22 Oleg Nesterov
2025-01-18 20:25 ` Kees Cook
0 siblings, 1 reply; 2+ messages in thread
From: Oleg Nesterov @ 2025-01-18 16:22 UTC (permalink / raw)
To: Kees Cook, Andy Lutomirski, Will Drewry, Thomas Bogendoerfer
Cc: linux-mips, linux-kernel
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.
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Q: arch/mips && __secure_computing(sd) with sd != NULL
2025-01-18 16:22 Q: arch/mips && __secure_computing(sd) with sd != NULL Oleg Nesterov
@ 2025-01-18 20:25 ` Kees Cook
0 siblings, 0 replies; 2+ messages in thread
From: Kees Cook @ 2025-01-18 20:25 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Andy Lutomirski, Will Drewry, Thomas Bogendoerfer, linux-mips,
linux-kernel
On Sat, Jan 18, 2025 at 05:22:38PM +0100, Oleg Nesterov wrote:
> Note that if we change arch/mips we can do more cleanups, in particular
> __secure_computing(sd) no longer needs the argument.
Yeah, seems like reasonable clean-up. The argument is a leftover from
x86 having sd pre-populated under certain paths.
--
Kees Cook
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-01-18 20:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-18 16:22 Q: arch/mips && __secure_computing(sd) with sd != NULL Oleg Nesterov
2025-01-18 20:25 ` Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox