linux-kernel - Re: [RFC] Don't create sframes during build

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: <7b45d196-063e-4e76-b08b-ec2bcc111328@linux.ibm.com>
Date: Thu, 29 Jan 2026 10:13:03 +0100
From: Jens Remus <jremus@...ux.ibm.com>
To: Matthias Klose <doko@...ian.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kbuild@...r.kernel.org
Cc: Arnd Bergmann <arnd@...db.de>, Josh Poimboeuf <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Nathan Chancellor
 <nathan@...nel.org>,
        Nicolas Schier <nicolas.schier@...ux.dev>,
        Binutils <binutils@...rceware.org>, Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [RFC] Don't create sframes during build

On 9/4/2025 4:02 PM, Matthias Klose wrote:
> [ CCing binutils@...rceware.org ]
> 
> On 9/4/25 15:18, Sebastian Andrzej Siewior wrote:
>> Hi,
>>
>> gcc in Debian, starting with 15.2.0-2, 14.3.0-6 enables sframe
>> generation. Unless options like -ffreestanding are passed. Since this
>> isn't done, there are a few warnings during compile
> 
> If there are other options when sframe shouldn't be enabled, please tell.
> 
> Gentoo chose another approach, enabling sframe unconditionally in gas,
> unless disabled by --gsframe=no.

...

>> followed by a boom
>> |   LD      .tmp_vmlinux1
>> | ld: error: unplaced orphan section `.sframe' from `vmlinux.o'
>>
>> We could drop the sframe during the final link but this does not get rid
>> of the objtool warnings so we would have to ignore them. But we don't
>> need it. So what about the following:

Instead of dropping .sframe for kernel during final link it would be
better not to generate it to save some CPU cycles and disk space.

>>
>> diff --git a/Makefile b/Makefile
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -886,6 +886,8 @@ ifdef CONFIG_CC_IS_GCC
>>   KBUILD_CFLAGS    += $(call cc-option,--param=allow-store-data-races=0)
>>   KBUILD_CFLAGS    += $(call cc-option,-fno-allow-store-data-races)
>>   endif
>> +# No sframe generation for kernel if enabled by default
>> +KBUILD_CFLAGS    += $(call cc-option,-Xassembler --gsframe=no)
>>     ifdef CONFIG_READABLE_ASM
>>   # Disable optimizations that make assembler listings hard to read.
> This is what I chose for package builds that need disablement of sframe.

What about:

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -906,6 +906,11 @@ KBUILD_CFLAGS	+= $(call cc-option,--param=allow-store-data-races=0)
 KBUILD_CFLAGS	+= $(call cc-option,-fno-allow-store-data-races)
 endif

+# No .sframe generation for kernel if enabled in assembler by default
+CC_FLAGS_SFRAME	:= $(call as-option,-Wa$(comma)--gsframe=no)
+KBUILD_CFLAGS	+= $(CC_FLAGS_SFRAME)
+KBUILD_AFLAGS	+= $(CC_FLAGS_SFRAME)
+
 ifdef CONFIG_READABLE_ASM
 # Disable optimizations that make assembler listings hard to read.
 # reorder blocks reorders the control in the function

Generation of .sframe in vDSO can override that default.  If archs like
arm64 want to enable .sframe for kernel they can introduce a kernel
option (e.g. SFRAME) that changes the default.

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@...ibm.com / jremus@...ux.ibm.com

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/