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] [day] [month] [year] [list]

Message-ID: <xo2ro446awhsd7i55shx6tlz6s2azuown4xk6zfm7ie4zz2nqc@244onpurkvy3>
Date: Wed, 17 Sep 2025 16:41:41 -0700
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 Thu, Sep 04, 2025 at 10:38:50PM +0000, Dylan Hatch wrote:
> +noinline notrace int arch_stack_walk_reliable(
> +				stack_trace_consume_fn consume_entry,
> +				void *cookie, struct task_struct *task)
> +{
> +	struct kunwind_reliable_consume_entry_data data = {
> +		.consume_entry = consume_entry,
> +		.cookie = cookie,
> +		.unreliable = false,
> +	};
> +
> +	kunwind_stack_walk(arch_kunwind_reliable_consume_entry, &data, task, NULL);
> +
> +	if (data.unreliable)
> +		return -EINVAL;

As far I can tell, the *only* error condition being checked is if it
(successfully) fell back to frame pointers.

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).

-- 
Josh