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: <lhuikfniop1.fsf@oldenburg.str.redhat.com>
Date: Thu, 06 Nov 2025 08:51:22 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Indu Bhagat <indu.bhagat@...cle.com>
Cc: Fangrui Song <maskray@...rceware.org>,
  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

* Indu Bhagat:

> PLT stubs may use stack (push to stack). As per the document "A null
> frame (MODE = 8) is the simplest possible frame, with no allocated
> stack of either kind (hence no saved registers)".  So null frame can
> be used for PLT only if the functions invoking the PLT stub were using
> an RBP-based frame.  Isnt it ?

I think I said this before, but I don't think new toolchain features
need to support lazy binding.  Without lazy bindings, the PLT stubs do
not change the stack pointer or frame pointer and just make a tail call.

Do you see a need for continued support of lazy binding?

Thanks,
Florian