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: <eo5fod6csuininieur2lm6bxunmpbk6n3wtxajamrwqqpae3ja@o3eqwfp3u6su>
Date: Mon, 17 Nov 2025 15:01:37 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Dylan Hatch <dylanbhatch@...gle.com>
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.

On Fri, Nov 14, 2025 at 10:44:20PM -0800, Dylan Hatch wrote:
> 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?

Right, any sframe error it encounters along the way (including missing
sframe) would be a reason to mark it as unreliable.

> 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?

For sframe v3, I believe Indu is planning to add support for marking the
outermost frame.  That would be one definitive way to know that the
stack trace made it to the end.

Or, if the entry-from-user pt_regs frame is always stored at a certain
offset compared to the end of the task stack page, that might be another
way.

-- 
Josh