linux-kernel - Re: [PATCH v2] 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: <CAHsH6GtmcDFzxtju1qpE9nyXya3JkKXcyGfvE1MS4UtdyRsHnw@mail.gmail.com>
Date: Thu, 30 Jan 2025 08:29:26 -0800
From: Eyal Birger <eyal.birger@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: Jiri Olsa <olsajiri@...il.com>, luto@...capital.net, wad@...omium.org, 
	oleg@...hat.com, 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, 
	andrii.nakryiko@...il.com, rostedt@...dmis.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 v2] seccomp: passthrough uretprobe systemcall without filtering

On Thu, Jan 30, 2025 at 7:57 AM Kees Cook <kees@...nel.org> wrote:
>
> On Thu, Jan 30, 2025 at 07:05:42AM -0800, Eyal Birger wrote:
> > So if we go with the suggestion above, we'll support the theoretical
> > __NR_uretprobe_32 for filtered seccomp, but not for strict seccomp, and
> > that's ok because strict seccomp is less common?
>
> It's so uncommon I regularly consider removing it entirely. :)
>
> > Personally I'd prefer to limit the scope of this fix to the problem we
> > are aware of, and not possible problems should someone decide to reimplement
> > uretprobes on different archs in a different way. Especially as this fix needs
> > to be backmerged to stable kernels.
> > So my personal preference would be to avoid __NR_uretprobe_32 in this patch
> > and deal with it if it ever gets implemented.
>
> That's fine, but I want the exception to be designed to fail closed
> instead of failing open. I think my proposed future-proof check does
> this.

I think it does. I think the code in the patch does too, since it
avoids the special handling for compat, so defaults to the existing
behavior which blocks the syscall.

Eyal.