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: <20251030102626.GR3245006@noisy.programming.kicks-ass.net>
Date: Thu, 30 Oct 2025 11:26:26 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Fangrui Song <maskray@...rceware.org>
Cc: 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 Wed, Oct 29, 2025 at 11:53:32PM -0700, Fangrui Song wrote:
> I've been following the SFrame discussion and wanted to share some
> concerns about its viability for userspace adoption, based on concrete
> measurements and comparison with existing compact unwind
> implementations in LLVM.
> 
> **Size overhead concerns**
> 
> Measurements on a x86-64 clang binary show that .sframe (8.87 MiB) is
> approximately 10% larger than the combined size of .eh_frame and
> .eh_frame_hdr (8.06 MiB total).  This is problematic because .eh_frame
> cannot be eliminated - it contains essential information for restoring
> callee-saved registers, LSDA, and personality information needed for
> debugging (e.g. reading local variables in a coredump) and C++
> exception handling.
> 
> This means adopting SFrame would result in carrying both formats, with
> a large net size increase.

So the SFrame unwinder is fairly simple code, but what does an .eh_frame
unwinder look like? Having read most of the links in your email, there
seem to be references to DWARF byte code interpreters and stuff like
that.

So while the format compactness is one aspect, the thing I find no
mention of, is the unwinder complexity.

There have been a number of attempts to do DWARF unwinding in
kernel space and while I think some architecture do it, x86_64 has had
very bad experiences with it. At some point I think Linus just said no
more, no DWARF, not ever.

So from a situation where compilers were generating bad CFI unwind
information, a horribly complex unwinder that could crash the kernel
harder than the thing it was reporting on and manual CFI annotations in
assembly that were never quite right, objtool and ORC were born.

The win was many:

 - simple robust unwinder
 - no manual CFI annotations that could be wrong
 - no reliance on compilers that would get it wrong

and I think this is where SFrame came from. I don't think the x86_64
Linux kernel will ever natively adopt SFrame, ORC works really well for
us.

However, we do need something to unwind userspace. And yes, personally
I'm in the frame-pointer camp, that's always worked well for me.
Distro's however don't seem to like it much, which means that every time
I do have to profile something userspace, I get to rebuild all the
relevant code with framepointers on (which is not hard, but tedious).

Barring that, we need something for which the unwind code is simple and
robust -- and I *think* this has disqualified .eh_frame and full on
DWARF.

And this is again where SFrame comes in -- its unwinder is simple,
something we can run in kernel space.

I really don't much care for the particulars, and frame pointers work
for me -- but I do care about the kernel unwinder code. It had better be
simple and robvst.

So if you want us to use .eh_frame, great, show us a simple and robust
unwinder.