| 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
| ||
|
Message-ID: <22bc8f74-1943-4ceb-bc6b-ea404ba013d9@linux.ibm.com>
Date: Mon, 9 Feb 2026 17:45:33 +0100
From: Jens Remus <jremus@...ux.ibm.com>
To: "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org,
x86@...nel.org, linux-mm@...ck.org,
Josh Poimboeuf <jpoimboe@...nel.org>,
Steven Rostedt <rostedt@...nel.org>,
Indu Bhagat <indu.bhagat@...cle.com>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
Jiri Olsa <jolsa@...nel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andrii Nakryiko <andrii@...nel.org>,
"Jose E. Marchesi" <jemarch@....org>,
Beau Belgrave <beaub@...ux.microsoft.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Florian Weimer <fweimer@...hat.com>, Kees Cook <kees@...nel.org>,
"Carlos O'Donell" <codonell@...hat.com>, Sam James <sam@...too.org>,
Dylan Hatch <dylanbhatch@...gle.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Hildenbrand <david@...nel.org>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Michal Hocko
<mhocko@...e.com>, Mike Rapoport <rppt@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>, Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
"Steven Rostedt (Google)" <rostedt@...dmis.org>
Subject: Re: [PATCH v8 6/6] x86/vdso: Enable sframe generation in VDSO
On 2/7/2026 12:08 AM, H. Peter Anvin wrote:
> On 2026-02-06 11:36, Jens Remus wrote:
>> From: Josh Poimboeuf <jpoimboe@...nel.org>
>>
>> Enable sframe generation in the VDSO library so kernel and user space
>> can unwind through it.
>>
>> SFrame isn't supported for x32 or x86-32. Discard .sframe sections for
>> those VDSOs.
>>
>> [ Jens Remus: Add support for SFrame V3. Prevent GNU_SFRAME program
>> table entry to empty .sframe section. ]
>>
>
> This will not break the x86-32 build if the assembler encounters .sframe?
I cannot follow. Assembler option --gsframe-3 is only specified in
vdso64/Makefile if CONFIG_AS_SFRAME3, which affects the x86-64 and x32
VDSOs. The latter as the x32 VDSO is built from x86-64 objects
converted to x86-32 objects using the X32 build step. Assembler
directive ".cfi_sections .sframe" is no longer used in dwarf2.h, which
affected the x86-32 VDSO if cross build on x86-64 (so that
CONFIG_AS_SFRAME3=y).
The reason to discard .sframe in the common VDSO linker script if
!KEEP_SFRAME is to remove it from x32 VDSO (built from x86-64 objects
having .sframe). It should also prevent linker errors from linkers that
do not support R_X86_64_PC64 in x32 mode, such as the meanwhile fixed
GNU linker:
https://www.sourceware.org/bugzilla/show_bug.cgi?id=33807
>
>> Notes (jremus):
>> Changes in v8:
>> - Discard .sframe for x32 and x86-32 VDSOs. (Josh/Indu)
>> Note that the use of KEEP_SFRAME enables to define it for x86-64
>> VDSO only. Unlike CONFIG_AS_SFRAME, which may also be defined
>> for x32 and x86-32 VDSO. In x32 VDSO it would result in superfluous
>> .sframe (copied from the x86-64 build - could be removed in X32
>> build step). In x86-32 VDSO it would cause a bogus GNU_SFRAME
>> program table entry.
>
> For x32, this would be a "valid" sframe, right, even if the tools currently
> don't know how to consume it (and potentially never will)? If so, is there
> really any reason to explicitly remove it?
I am not an x86 expert. IIUC the x32 ABI uses 4-byte pointers. But GCC
with option -mx32 emits DWARF that suggests that at least the return
address (RA) and frame pointer (FP; rbp) are still pushed as 8-byte
values on the stack, which would be relevant for SFrame:
00000000 <foo>:
0: 55 push %rbp
1: 89 e5 mov %esp,%ebp
...
LOC CFA rbp ra
0000000000000000 rsp+8 u c-8 <-- suggests RA is 8-bytes on stack
0000000000000001 rsp+16 c-16 c-8 <-- suggests FP is 8-bytes on stack
...
That could mean that technically the .sframe would be mostly valid. The
fixed RA offset of -8 would be correct, the variable FP offset would be
tracked, and the implicit SP rule SP=CFA should be correct as well. But
the SFrame header would incorrectly specify AMD64 as ABI/arch ID instead
of ILP32 (if I got the ELF x86-64-ABI psABI [1] correct).
AFAIK SFrame does not officially support ILP32. At least GNU assembler
does not:
$ printf ".cfi_startproc\n.cfi_endproc\n" | as --gsframe-3 --x32 ; echo $?
Assembler messages:
{standard input}: Error: .sframe not supported for target
1
My take would be that it would be better to build x32 VDSO without
.sframe (or discard .sframe from x32 VDSO), unless it is officially
supported.
@Indu: What are your thoughts as SFrame maintainer?
[1]: ELF x86-64-ABI psABI,
https://gitlab.com/x86-psABIs/x86-64-ABI
>> /*
>> * Text is well-separated from actual data: there's plenty of
>> * stuff that isn't used at runtime in between.
>> @@ -80,6 +87,10 @@ SECTIONS
>> *(.discard)
>> *(.discard.*)
>> *(__bug_table)
>> +#ifndef KEEP_SFRAME
>> + *(.sframe)
>> + *(.sframe.*)
>> +#endif
>
> This #ifndef is actually not necessary: if we have already "consumed" the
> .sframe* sections they will not be encountered here.
It is necessary to remove .sframe from x86-64 objects (created by the
x86-64 VDSO build) converted to x86-32 objects in the X32 build step for
x32 VDSO, provided SFrame is not supported for x32. The x86-64 VDSO has
.sframe, as the x86-64 VDSO linker script defines KEEP_SFRAME. The x32
VDSO has .sframe removed, as the x32 linker script does not define
KEEP_SFRAME.
An alternative to the #ifndef (or #if !KEEP_SFRAME) would be to remove
the .sframe in the X32 build step:
diff --git a/arch/x86/entry/vdso/vdso64/Makefile b/arch/x86/entry/vdso/vdso64/Makefile
@@ -23,14 +24,14 @@ include $(src)/../common/Makefile.include
#
# Build x32 vDSO image:
# 1. Compile x32 vDSO as 64bit.
-# 2. Convert object files to x32.
+# 2. Convert object files to x32 and remove .sframe.
# 3. Build x32 VDSO image with x32 objects, which contains 64bit codes
# so that it can reach 64bit address space with 64bit pointers.
#
# Convert 64bit object file to x32 for x32 vDSO.
quiet_cmd_x32 = X32 $@
- cmd_x32 = $(OBJCOPY) -O elf32-x86-64 $< $@
+ cmd_x32 = $(OBJCOPY) -O elf32-x86-64 -R .sframe $< $@
$(obj)/%-x32.o: $(obj)/%.o FORCE
$(call if_changed,x32)
KEEP_SFRAME (or then maybe better HAVE_SFRAME) would then still be
required to only emit a program table entry, if .sframe was generated.
Note that AS_SFRAME only indicates whether the assembler supports to
generate .sframe. Not whether if it should actually be done. That is
selected by adding the --gsframe-3 assembler option and defining
KEEP_SFRAME to true, which is done in the respective VDSO Makefile and
linker script.
> I would prefer to have KEEP_SFRAME always defined (as true or false, and using
> #if) instead of using #ifdef. I believe that also means you can do:
>
> #define KEEP_SFRAME IS_ENABLED(CONFIG_AS_SFRAME)
>
> ... instead of #ifdef.
The following works and indeed looks nicer with #if KEEP_SFRAME. Will
wait for further feedback on whether or not to discard .sframe in x32
VDSO before sending a v9.
diff --git a/arch/x86/entry/vdso/common/vdso-layout.lds.S b/arch/x86/entry/vdso/common/vdso-layout.lds.S
@@ -60,7 +60,7 @@ SECTIONS
*(.eh_frame.*)
} :text
-#ifdef KEEP_SFRAME
+#if KEEP_SFRAME
.sframe : {
KEEP (*(.sframe))
*(.sframe.*)
@@ -87,7 +87,7 @@ SECTIONS
*(.discard)
*(.discard.*)
*(__bug_table)
-#ifndef KEEP_SFRAME
+#if !KEEP_SFRAME
*(.sframe)
*(.sframe.*)
#endif
@@ -116,7 +116,7 @@ PHDRS
dynamic PT_DYNAMIC PF_R;
note PT_NOTE PF_R;
eh_frame_hdr PT_GNU_EH_FRAME PF_R;
-#ifdef KEEP_SFRAME
+#if KEEP_SFRAME
sframe PT_GNU_SFRAME PF_R;
#endif
gnu_stack PT_GNU_STACK PF_RW;
diff --git a/arch/x86/entry/vdso/vdso32/vdso32.lds.S b/arch/x86/entry/vdso/vdso32/vdso32.lds.S
@@ -10,6 +10,7 @@
#include <asm/page.h>
#define BUILD_VDSO32
+#define KEEP_SFRAME false
#include "common/vdso-layout.lds.S"
diff --git a/arch/x86/entry/vdso/vdso64/vdso64.lds.S b/arch/x86/entry/vdso/vdso64/vdso64.lds.S
@@ -8,10 +8,7 @@
*/
#define BUILD_VDSO64
-
-#ifdef CONFIG_AS_SFRAME
-# define KEEP_SFRAME
-#endif
+#define KEEP_SFRAME (CONFIG_AS_SFRAME)
#include "common/vdso-layout.lds.S"
diff --git a/arch/x86/entry/vdso/vdso64/vdsox32.lds.S b/arch/x86/entry/vdso/vdso64/vdsox32.lds.S
@@ -8,6 +8,7 @@
*/
#define BUILD_VDSOX32
+#define KEEP_SFRAME false
#include "common/vdso-layout.lds.S"
Thanks and 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/
Powered by blists - more mailing lists