linux-kernel - Re: [PATCH v2 6/6] unwind: arm64: Add reliable stacktrace with sframe unwinder.

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: <CADBMgpyVis+fRHLOv6BRPrT+0r8846MOutkmOgMbqytLVXh9Ag@mail.gmail.com>
Date: Fri, 14 Nov 2025 22:44:20 -0800
From: Dylan Hatch <dylanbhatch@...gle.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Indu Bhagat <indu.bhagat@...cle.com>, 
	Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Jiri Kosina <jikos@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Weinan Liu <wnliu@...gle.com>, 
	Mark Rutland <mark.rutland@....com>, Ian Rogers <irogers@...gle.com>, 
	linux-toolchains@...r.kernel.org, linux-kernel@...r.kernel.org, 
	live-patching@...r.kernel.org, joe.lawrence@...hat.com, 
	Puranjay Mohan <puranjay@...nel.org>, Song Liu <song@...nel.org>, 
	Prasanna Kumar T S M <ptsm@...ux.microsoft.com>
Subject: Re: [PATCH v2 6/6] unwind: arm64: Add reliable stacktrace with sframe unwinder.

Sorry for the slow reply on this, I'm going to try and get a v3 out
sometime after next week.

On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> As far I can tell, the *only* error condition being checked is if it
> (successfully) fell back to frame pointers.

By checking/handling error conditions, do you mean just marking the
state as unreliable in any case where the unwind isn't successful with
SFrame? I'm thinking if I can make the unwind_next_frame_sframe() code
path handle the end of the stack correctly on its own, I can more
strictly mark the trace as unreliable if it encounters any error.

>
> What if there was some bad or missing sframe data?  Or some unexpected
> condition on the stack?
>
> Also, does the exception handling code have correct cfi/sframe metadata?
>
> In order for it to be "reliable", we need to know the unwind reached the
> end of the stack (e.g., the task pt_regs frame, from entry-from-user).

It looks like the frame-pointer based method of handling the end of
the stack involves calling kunwind_next_frame_record_meta() to extract
and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think
this currently assumes (based on the definition of 'struct
frame_record') that the next FP and PC are right next to each other,
alongside the meta type. But the sframe format stores separate entries
for the FP and RA offsets, which makes extracting the meta type from
this information a little bit murky to me.

Would it make sense to fall back to the frame pointer method for the
final stack frame? Or I guess I could define a new sframe-friendly
meta frame record format?

Thanks,
Dylan