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

Message-ID: <733c2079-2cd8-48ef-809e-b42bf74b3bd9@oracle.com>
Date: Thu, 6 Nov 2025 13:02:11 -0800
From: Indu Bhagat <indu.bhagat@...cle.com>
To: Florian Weimer <fweimer@...hat.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

On 11/5/25 11:51 PM, Florian Weimer wrote:
> * 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?
> 

(Yes, you did mention this before in another thread on Binutils.)

My thinking has been: some linker emulations default to lazy (I guess 
the reason is changing the default is difficult).  So, users may end up 
continuing with lazy bindings unknowingly ?

But I guess not designing new toolchain features to support lazy binding 
seems reasonable.

Thanks