linux-kernel - Re: [PATCH v16 0/4] perf: Support the deferred unwinding infrastructure

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: <lhuldkmujom.fsf@oldenburg.str.redhat.com>
Date: Tue, 04 Nov 2025 12:22:01 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jens Remus <jremus@...ux.ibm.com>,  Steven Rostedt <rostedt@...nel.org>,
  linux-kernel@...r.kernel.org,  linux-trace-kernel@...r.kernel.org,
  bpf@...r.kernel.org,  x86@...nel.org,  Masami Hiramatsu
 <mhiramat@...nel.org>,  Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>,  Josh Poimboeuf <jpoimboe@...nel.org>,
  Ingo Molnar <mingo@...nel.org>,  Jiri Olsa <jolsa@...nel.org>,  Arnaldo
 Carvalho de Melo <acme@...nel.org>,  Namhyung Kim <namhyung@...nel.org>,
  Thomas Gleixner <tglx@...utronix.de>,  Andrii Nakryiko
 <andrii@...nel.org>,  Indu Bhagat <indu.bhagat@...cle.com>,  "Jose E.
 Marchesi" <jemarch@....org>,  Beau Belgrave <beaub@...ux.microsoft.com>,
  Linus Torvalds <torvalds@...ux-foundation.org>,  Andrew Morton
 <akpm@...ux-foundation.org>,  Sam James <sam@...too.org>,  Kees Cook
 <kees@...nel.org>,  Carlos O'Donell <codonell@...hat.com>,  Heiko Carstens
 <hca@...ux.ibm.com>,  Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH v16 0/4] perf: Support the deferred unwinding
 infrastructure

* Peter Zijlstra:

> +/*
> + * Heuristic-based check if uprobe is installed at the function entry.
> + *
> + * Under assumption of user code being compiled with frame pointers,
> + * `push %rbp/%ebp` is a good indicator that we indeed are.
> + *
> + * Similarly, `endbr64` (assuming 64-bit mode) is also a common pattern.
> + * If we get this wrong, captured stack trace might have one extra bogus
> + * entry, but the rest of stack trace will still be meaningful.
> + */
> +bool is_uprobe_at_func_entry(struct pt_regs *regs)

Is this specifically for uprobes?  Wouldn't it make sense to tell the
kernel when the uprobe is installed whether the frame pointer has been
set up at this point?  Userspace can typically figure this out easily
enough (it's not much more difficult to find the address of the
function).

Thanks,
Florian