linux-kernel - Re: [PATCH v8 6/6] x86/vdso: Enable sframe generation in VDSO

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b074b10e-6b3e-4c69-a986-6b2eb665e535@zytor.com>
Date: Mon, 9 Feb 2026 11:13:58 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Jens Remus <jremus@...ux.ibm.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 2026-02-09 08:45, Jens Remus wrote:
> 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
> 

OK, the linker not handing R_X86_64_PC64 is probably a good enough reason to
discard .sframe.

The x32 ABI and object format is explicitly intended to be as close to the
x86-64 as possible; it even uses the same architectural identifier. That's
pretty much the reason we don't even bother recompiling the objects in the
first place; the 64-bit objects can simply be downconverted from ELF64 to
ELF32. This also means that the compiler doesn't need to support x32, although
objcopy and ld does.

This also means the DWARF data is the one generated for 64 bits.

This works because the following is true for all vdso entrypoints:
	- No vdso entry point access pointers or explicit "long"s *in memory*.
	  (The latter formally violates POSIX for struct timespec, but that
	   was a deliberate decision imposed by Linus at the time the x32 API
	   was defined: "no 32-bit time_t in a new ABI.")
	- No vdso entry point calls system calls that do, either.
	- No vdso entry point takes a *signed* long as an argument.
	- No vdso entry point calls system calls that differ in behavior
	  between x86-64 and x32, making it OK to call the 64-bit system call
	  from an x32 process.

"unsigned long" and pointers *can* be safely passed in argument registers
(because the architecture will zero-extend those registers), and in addition
"signed long" *can* be safely passed as returns.

If ANY of the constraints above were ever violated, OR the binary format would
start diverging to the point that objcopy can't properly convert it, then we
would need to start compiling the x32 binaries separately.


> 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.

I think ld tripping over a bug justifies dropping .sframe at this point. *Make
sure* to document that in the checkin, and add a comment to vdso32.lds.S that
that is the motivation, so that if x32 gains support for .sframe in the future
(which should be simple enough, since the formats are so similar) we don't get
stuck in some kind of cargo cult programming problem.

It also will avoid issues on the off chance .sframe ends up being defined
differently for x32 for some reason, perhaps for consistency with other 32-bit
platforms.


Include the version of binutils which fixed the problem in your comments.


	-hpa



> 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)

This needs to be IS_ENABLED(CONFIG_AS_SFRAME). Otherwise you get either "y" or
"CONFIG_AS_SFRAME", neither of which are what you want.

>  #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

Is "false" supported by all appropriate cpp versions? "0" is probably a safer
choice, and matches the IS_ENABLED() output anyway.

	-hpa