linux-kernel - Re: [PATCH v12 00/14] unwind_user: x86: 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: <789666b6-fba9-4067-bae0-60a37b7c8fd3@efficios.com>
Date: Wed, 2 Jul 2025 12:20:52 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Kees Cook <kees@...nel.org>, Steven Rostedt <rostedt@...dmis.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 bpf@...r.kernel.org, x86@...nel.org, Masami Hiramatsu <mhiramat@...nel.org>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...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>, Jens Remus
 <jremus@...ux.ibm.com>, Andrew Morton <akpm@...ux-foundation.org>,
 Jens Axboe <axboe@...nel.dk>, Florian Weimer <fweimer@...hat.com>
Subject: Re: [PATCH v12 00/14] unwind_user: x86: Deferred unwinding
 infrastructure

On 2025-07-02 10:56, Kees Cook wrote:
> On Tue, Jul 01, 2025 at 07:26:19PM -0400, Steven Rostedt wrote:
>> On Tue, 1 Jul 2025 15:49:23 -0700 Kees Cook <kees@...nel.org> wrote:
>>> Okay, I've read the cover letter and this wiki page, but I am dense: why
>>> does the _kernel_ want to do this? Shouldn't it only be userspace that
>>> cares about userspace unwinding? I don't use perf, ftrace, and ebpf
>>> enough to make this obvious to me, I guess. ;)
>> [...]
>> Anyway, yeah, it's something that has a ton of interest, as it's the way
>> for tools like perf to give nice graphs of where user space bottlenecks
>> exist.
> 
> Right! Yeah, I know it's very wanted -- I wasn't saying "don't this in
> the kernel", but quite literally, "*I* am missing something about why
> this is so important." :) And thank you, now I see: the sampling-based
> profiling of userspace must happen via the kernel.
> 

I should add that once we have this in place for perf sampling,
it enables the following additional use-cases:

- Sample stack traces from specific tracepoints, e.g. system call
   entry. This allows associating the kernel tracepoints with their
   userspace call chain (causality) without requiring tracing of
   userspace.

- Implement a system call that allows a userspace thread to use the
   kernel stack sampling facilities on itself rather than reimplement
   the stack walk and sframe registry handling + decoding on the
   userspace side.

For this last point, it's only relevant because the infrastructure
will already be in place for stack sampling from the kernel. So we'd
eliminate duplication by allowing its use from userspace as well.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com