linux-kernel - Re: [PATCH] seccomp: passthrough uretprobe systemcall without filtering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250121174620.06a0c811@gandalf.local.home>
Date: Tue, 21 Jan 2025 17:46:20 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Jiri Olsa <olsajiri@...il.com>, Kees Cook <kees@...nel.org>, Eyal Birger
 <eyal.birger@...il.com>, luto@...capital.net, wad@...omium.org,
 oleg@...hat.com, ldv@...ace.io, mhiramat@...nel.org, andrii@...nel.org,
 alexei.starovoitov@...il.com, cyphar@...har.com, songliubraving@...com,
 yhs@...com, john.fastabend@...il.com, peterz@...radead.org,
 tglx@...utronix.de, bp@...en8.de, daniel@...earbox.net, ast@...nel.org,
 rafi@....io, shmulik.ladkani@...il.com, bpf@...r.kernel.org,
 linux-api@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 x86@...nel.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] seccomp: passthrough uretprobe systemcall without
 filtering

On Tue, 21 Jan 2025 14:38:09 -0800
Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:

> You said yourself that sys_uretprobe is no different from rt_sigreturn
> and restart_syscall, so why would we rollback sys_uretprobe if we
> wouldn't rollback rt_sigreturn/restart_syscall? Given it's impossible,
> generally speaking, to know if userspace is blocking the syscall (and
> that can change dynamically and very frequently), any improvement or
> optimization that kernel would do with the help of special syscall is
> now prohibited, effectively. That doesn't seem wise to restrict the
> kernel development so much just because libseccomp blocks any unknown
> syscall by default.

What happens if the system call is hit when there was no uprobe attached to
it? Perhaps it should segfault? That is, this system call is only used when
the kernel attaches it, if the kernel did not attach it, perhaps there's
some malicious code that is trying to use it for some CVE corner case. But
if it always crashes when added, the only thing the malicious code can do
by adding this system call is to crash the application. That shouldn't be a
problem, as if malicious code can add a system call, it can also change the
code to crash as well.

Perhaps the security folks would feel better if there were other
protections against this system call when not used as expected?

-- Steve