linux-kernel - Re: Concerns about SFrame viability for userspace stack walking

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: <20251030133323.3a81c02c@gandalf.local.home>
Date: Thu, 30 Oct 2025 13:33:23 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Fangrui Song <maskray@...rceware.org>
Cc: Peter Zijlstra <peterz@...radead.org>, linux-toolchains@...r.kernel.org,
 linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Concerns about SFrame viability for userspace stack walking

On Thu, 30 Oct 2025 09:48:50 -0700
Fangrui Song <maskray@...rceware.org> wrote:

> If SFrame is exclusively a kernel-space feature, it could be
> implemented entirely within objtool – similar to how objtool --link
> --orc generates ORC info for vmlinux.o. This approach would eliminate
> the need for any modifications to assemblers and linkers, while
> allowing SFrame to evolve in any incompatible way.

I'm not sure what you mean here. Yes, it is implemented in the kernel, but
it is reading user space applications to get the sframes from them.

Every running application would need this information for its executable.
The kernel is dependent on user space having this.

The only thing the kernel is doing is reading the sframe tables associated
with the running applications to be able to walk their stacks at runtime to
do profiling. As Peter asked, the kernel cares extensively on that walking
being simple. If something goes wrong, you compromise the entire machine.

-- Steve