[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250121164435.GA17215@redhat.com>
Date: Tue, 21 Jan 2025 17:44:35 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Jiri Olsa <olsajiri@...il.com>, Eyal Birger <eyal.birger@...il.com>,
Kees Cook <kees@...nel.org>, luto@...capital.net, wad@...omium.org,
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, andrii.nakryiko@...il.com,
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 01/21, Steven Rostedt wrote:
>
> I think this may have been mentioned, but is there a way that the kernel
> could know that this system call is being monitored by seccomp, and if so,
> just stick with the interrupt version? If not, enable the system call?
Consider
int func_to_uretprobe()
{
seccomp(SECCOMP_SET_MODE_STRICT/whatever);
return 123;
}
by the time it is called, the kernel can't know that this function will
call seccomp/install-the-filters/etc, so prepare_uretprobe() can't know
if it is safe to use uretprobe or not.
Oleg.
Powered by blists - more mailing lists