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: <CAHsH6GvcOjNh8VMpPs9CzyVSCOB+92zRj_3ZeDOd6APySWdm5Q@mail.gmail.com>
Date: Tue, 21 Jan 2025 15:13:52 -0800
From: Eyal Birger <eyal.birger@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, Jiri Olsa <olsajiri@...il.com>, 
	Kees Cook <kees@...nel.org>, 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, Jan 21, 2025 at 2:46 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> 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?

Isn't that the case already, or maybe I misunderstood what Jiri wrote [1]:

> On Sun, Jan 19, 2025 at 2:44 AM Jiri Olsa <olsajiri@...il.com> wrote:
> that's correct, uretprobe syscall is installed by kernel to special user
> memory map and it can be executed only from there and if process calls it
> from another place it receives sigill

Eyal.

[1] https://lore.kernel.org/lkml/Z4zXlaEMPbiYYlQ8@krava/