linux-kernel - Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel

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: <cxxj6lzs226ost6js5vslm52bxblknjwd6llmu24h3bk742zjh@7iwwi5bafysq>
Date: Mon, 17 Nov 2025 16:10:46 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Dylan Hatch <dylanbhatch@...gle.com>, 
	Puranjay Mohan <puranjay12@...il.com>, Song Liu <song@...nel.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>
Subject: Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel

On Mon, Nov 17, 2025 at 06:42:23PM -0500, Steven Rostedt wrote:
> On Mon, 17 Nov 2025 15:06:32 -0800
> Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> 
> > The ORC unwinder marks the unwind "unreliable" if it has to fall back to
> > frame pointers.
> > 
> > But that's not a problem for livepatch because it only[*] unwinds
> > blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
> > 
> > [*] with one exception: the task calling into livepatch
> 
> It may be a problem with preempted tasks right? I believe with PREEMPT_LAZY
> (and definitely with PREEMPT_RT) BPF programs can be preempted.

In that case, then yes, that stack would be marked unreliable and
livepatch would have to go try and patch the task later.

If it were an isolated case, that would be fine, but if BPF were
consistently on the same task's stack, it could stall the completion of
the livepatch indefinitely.

I haven't (yet?) heard of BPF-induced livepatch stalls happening in
reality, but maybe it's only a matter of time :-/

To fix that, I suppose we would need some kind of dynamic ORC
registration interface.  Similar to what has been discussed with
sframe+JIT.

If BPF were to always use frame pointers then there would be only a very
limited set of ORC entries (either "frame pointer" or "undefined") for a
given BPF function and it shouldn't be too complicated.

-- 
Josh