linux-kernel - Re: [PATCHv6 perf/core 09/22] uprobes/x86: Add uprobe syscall to speed up uprobe

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: <CAEf4Bza-5u1j75YjvMdfgsEexv2W8nwikMaOUYpScie6ZWDOsg@mail.gmail.com>
Date: Wed, 3 Sep 2025 16:12:37 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jiri Olsa <olsajiri@...il.com>, Oleg Nesterov <oleg@...hat.com>, 
	Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, x86@...nel.org, 
	Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, 
	John Fastabend <john.fastabend@...il.com>, Hao Luo <haoluo@...gle.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Alan Maguire <alan.maguire@...cle.com>, David Laight <David.Laight@...lab.com>, 
	Thomas Weißschuh <thomas@...ch.de>, 
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCHv6 perf/core 09/22] uprobes/x86: Add uprobe syscall to
 speed up uprobe

On Wed, Sep 3, 2025 at 2:01 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Wed, Sep 03, 2025 at 10:56:10PM +0200, Jiri Olsa wrote:
>
> > > > +SYSCALL_DEFINE0(uprobe)
> > > > +{
> > > > +       struct pt_regs *regs = task_pt_regs(current);
> > > > +       struct uprobe_syscall_args args;
> > > > +       unsigned long ip, sp;
> > > > +       int err;
> > > > +
> > > > +       /* Allow execution only from uprobe trampolines. */
> > > > +       if (!in_uprobe_trampoline(regs->ip))
> > > > +               goto sigill;
> > >
> > > Hey Jiri,
> > >
> > > So I've been thinking what's the simplest and most reliable way to
> > > feature-detect support for this sys_uprobe (e.g., for libbpf to know
> > > whether we should attach at nop5 vs nop1), and clearly that would be
> > > to try to call uprobe() syscall not from trampoline, and expect some
> > > error code.
> > >
> > > How bad would it be to change this part to return some unique-enough
> > > error code (-ENXIO, -EDOM, whatever).
> > >
> > > Is there any reason not to do this? Security-wise it will be just fine, right?
> >
> > good question.. maybe :) the sys_uprobe sigill error path followed the
> > uprobe logic when things go bad, seem like good idea to be strict
> >
> > I understand it'd make the detection code simpler, but it could just
> > just fork and check for sigill, right?
>
> Can't you simply uprobe your own nop5 and read back the text to see what
> it turns into?

Sure, but none of that is neither fast, nor cheap, nor that simple...
(and requires elevated permissions just to detect)

Forking is also resource-intensive. (think from libbpf's perspective,
it's not cool for library to fork some application just to check such
a seemingly simple thing as whether to

The question is why all that? That SIGILL when !in_uprobe_trampoline()
is just paranoid. I understand killing an application if it tries to
screw up "protocol" in all the subsequent checks. But here it's
equally secure to just fail that syscall with normal error, instead of
punishing by death.