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: <202501300756.E473D10@keescook>
Date: Thu, 30 Jan 2025 07:57:52 -0800
From: Kees Cook <kees@...nel.org>
To: Eyal Birger <eyal.birger@...il.com>
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 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.

-- 
Kees Cook