[PATCH 0/2] s390/vdso: Fix GNU_EH_FRAME PHDR

[PATCH 0/2] s390/vdso: Fix GNU_EH_FRAME PHDR

[Jens Remus]

Patch 1 fixes the empty GNU_EH_FRAME program table header entry to
enable unwinders and stacktracers to locate the .eh_frame_hdr section.

Patch 2 uses symbolic constants for the PHDR permission flags to improve
readability and explicitly specifies the GNU_EH_FRAME PHDR to be read-
only.

Regards,
Jens


Jens Remus (2):
  s390/vdso: Pass --eh-frame-hdr to the linker
  s390/vdso: Use symbolic constants for the PHDR permission flags

 arch/s390/kernel/vdso/Makefile   |  3 ++-
 arch/s390/kernel/vdso/vdso.lds.S | 12 ++++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)


base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
-- 
2.53.0

[PATCH 1/2] s390/vdso: Pass --eh-frame-hdr to the linker

[Jens Remus]

Commit 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link
vDSO") accidentally broke the GNU_PTR_EH_FRAME program table entry in
the vDSO, causing it to be empty:

  $ readelf --program-headers arch/s390/kernel/vdso/vdso.so
  ...
  Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
  ...
    GNU_EH_FRAME   0x0000000000000000 0x0000000000000000 0x0000000000000000
                   0x0000000000000000 0x0000000000000000         0x8
  ...

Originally, the compiler would implicitly add --eh-frame-hdr when
invoking the linker, but when this Makefile was converted from invoking
the linker via the compiler, to invoking it directly, the option was
missed.

This is the s390 variant of x86 commit cd01544a268a ("x86/vdso: Pass
--eh-frame-hdr to the linker").

Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
 arch/s390/kernel/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kernel/vdso/Makefile b/arch/s390/kernel/vdso/Makefile
index fece5d975eaf..35c834b895ec 100644
--- a/arch/s390/kernel/vdso/Makefile
+++ b/arch/s390/kernel/vdso/Makefile
@@ -30,7 +30,8 @@ KBUILD_CFLAGS_VDSO := $(filter-out -fno-asynchronous-unwind-tables,$(KBUILD_CFLA
 KBUILD_CFLAGS_VDSO += -fPIC -fno-common -fno-builtin -fasynchronous-unwind-tables
 KBUILD_CFLAGS_VDSO += -fno-stack-protector $(DISABLE_KSTACK_ERASE)
 ldflags-y := -shared -soname=linux-vdso.so.1 \
-	     --hash-style=both --build-id=sha1 -T
+	     --hash-style=both --build-id=sha1 \
+	     $(call ld-option, --eh-frame-hdr) -T
 
 $(targets:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_VDSO)
 $(targets:%=$(obj)/%.dbg): KBUILD_AFLAGS = $(KBUILD_AFLAGS_VDSO)
-- 
2.53.0

Re: [PATCH 1/2] s390/vdso: Pass --eh-frame-hdr to the linker

[Jens Remus]

On 7/6/2026 5:19 PM, Jens Remus wrote:
> Commit 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link
> vDSO") accidentally broke the GNU_PTR_EH_FRAME program table entry in

s/GNU_PTR_EH_FRAME/GNU_EH_FRAME/ 

> the vDSO, causing it to be empty:
> 
>   $ readelf --program-headers arch/s390/kernel/vdso/vdso.so
>   ...
>   Program Headers:
>     Type           Offset             VirtAddr           PhysAddr
>                    FileSiz            MemSiz              Flags  Align
>   ...
>     GNU_EH_FRAME   0x0000000000000000 0x0000000000000000 0x0000000000000000
>                    0x0000000000000000 0x0000000000000000         0x8
>   ...
> 
> Originally, the compiler would implicitly add --eh-frame-hdr when
> invoking the linker, but when this Makefile was converted from invoking
> the linker via the compiler, to invoking it directly, the option was
> missed.
> 
> This is the s390 variant of x86 commit cd01544a268a ("x86/vdso: Pass
> --eh-frame-hdr to the linker").
> 
> Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO")
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.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/

Re: [PATCH 1/2] s390/vdso: Pass --eh-frame-hdr to the linker

[Ilya Leoshkevich]

On 7/6/26 17:19, Jens Remus wrote:
> Commit 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link
> vDSO") accidentally broke the GNU_PTR_EH_FRAME program table entry in
> the vDSO, causing it to be empty:
> 
>    $ readelf --program-headers arch/s390/kernel/vdso/vdso.so
>    ...
>    Program Headers:
>      Type           Offset             VirtAddr           PhysAddr
>                     FileSiz            MemSiz              Flags  Align
>    ...
>      GNU_EH_FRAME   0x0000000000000000 0x0000000000000000 0x0000000000000000
>                     0x0000000000000000 0x0000000000000000         0x8
>    ...
> 
> Originally, the compiler would implicitly add --eh-frame-hdr when
> invoking the linker, but when this Makefile was converted from invoking
> the linker via the compiler, to invoking it directly, the option was
> missed.
> 
> This is the s390 variant of x86 commit cd01544a268a ("x86/vdso: Pass
> --eh-frame-hdr to the linker").
> 
> Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO")
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
>   arch/s390/kernel/vdso/Makefile | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>

[PATCH 2/2] s390/vdso: Use symbolic constants for the PHDR permission flags

[Jens Remus]

While at it explicitly specify GNU_EH_FRAME PHDR to be read-only.

Inspired by x86 commit 8717b02b8c03 ("x86/entry/vdso: Include
GNU_PROPERTY and GNU_STACK PHDRs").

Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
 arch/s390/kernel/vdso/vdso.lds.S | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/s390/kernel/vdso/vdso.lds.S b/arch/s390/kernel/vdso/vdso.lds.S
index 7bec4de0e8e0..35ea7ede06c0 100644
--- a/arch/s390/kernel/vdso/vdso.lds.S
+++ b/arch/s390/kernel/vdso/vdso.lds.S
@@ -82,12 +82,16 @@ SECTIONS
  * We must supply the ELF program headers explicitly to get just one
  * PT_LOAD segment, and set the flags explicitly to make segments read-only.
  */
+#define PF_R	FLAGS(4)
+#define PF_RW	FLAGS(6)
+#define PF_RX	FLAGS(5)
+
 PHDRS
 {
-	text		PT_LOAD FILEHDR PHDRS FLAGS(5);	/* PF_R|PF_X */
-	dynamic		PT_DYNAMIC FLAGS(4);		/* PF_R */
-	note		PT_NOTE FLAGS(4);		/* PF_R */
-	eh_frame_hdr	PT_GNU_EH_FRAME;
+	text		PT_LOAD		PF_RX FILEHDR PHDRS;
+	dynamic		PT_DYNAMIC	PF_R;
+	note		PT_NOTE		PF_R;
+	eh_frame_hdr	PT_GNU_EH_FRAME	PF_R;
 }
 
 /*
-- 
2.53.0

Re: [PATCH 2/2] s390/vdso: Use symbolic constants for the PHDR permission flags

[Ilya Leoshkevich]

On 7/6/26 17:19, Jens Remus wrote:
> While at it explicitly specify GNU_EH_FRAME PHDR to be read-only.
> 
> Inspired by x86 commit 8717b02b8c03 ("x86/entry/vdso: Include
> GNU_PROPERTY and GNU_STACK PHDRs").
> 
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
>   arch/s390/kernel/vdso/vdso.lds.S | 12 ++++++++----
>   1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/s390/kernel/vdso/vdso.lds.S b/arch/s390/kernel/vdso/vdso.lds.S
> index 7bec4de0e8e0..35ea7ede06c0 100644
> --- a/arch/s390/kernel/vdso/vdso.lds.S
> +++ b/arch/s390/kernel/vdso/vdso.lds.S
> @@ -82,12 +82,16 @@ SECTIONS
>    * We must supply the ELF program headers explicitly to get just one
>    * PT_LOAD segment, and set the flags explicitly to make segments read-only.
>    */
> +#define PF_R	FLAGS(4)
> +#define PF_RW	FLAGS(6)

PF_RW seems to be unused
Intel uses it for gnu_stack, which we don't seem to have.


Anyway:

Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>

Re: [PATCH 2/2] s390/vdso: Use symbolic constants for the PHDR permission flags

[Jens Remus]

On 7/6/2026 7:06 PM, Ilya Leoshkevich wrote:
> On 7/6/26 17:19, Jens Remus wrote:
>> While at it explicitly specify GNU_EH_FRAME PHDR to be read-only.
>>
>> Inspired by x86 commit 8717b02b8c03 ("x86/entry/vdso: Include
>> GNU_PROPERTY and GNU_STACK PHDRs").
>>
>> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
>> ---
>>   arch/s390/kernel/vdso/vdso.lds.S | 12 ++++++++----
>>   1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/s390/kernel/vdso/vdso.lds.S b/arch/s390/kernel/vdso/vdso.lds.S
>> index 7bec4de0e8e0..35ea7ede06c0 100644
>> --- a/arch/s390/kernel/vdso/vdso.lds.S
>> +++ b/arch/s390/kernel/vdso/vdso.lds.S
>> @@ -82,12 +82,16 @@ SECTIONS
>>    * We must supply the ELF program headers explicitly to get just one
>>    * PT_LOAD segment, and set the flags explicitly to make segments read-only.
>>    */
>> +#define PF_R    FLAGS(4)
>> +#define PF_RW    FLAGS(6)
> 
> PF_RW seems to be unused
> Intel uses it for gnu_stack, which we don't seem to have.

Good catch, that slipped through.

I wondered whether we should also add a GNU_STACK PHDR in a separate
patch - similar to x86 and for the same reasons, as some of the .o files
linked into vdso.so do have a .note.GNU-stack.

> Anyway:
> 
> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>

Thanks!

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.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/

Re: [PATCH 0/2] s390/vdso: Fix GNU_EH_FRAME PHDR

[Heiko Carstens]

On Mon, Jul 06, 2026 at 05:19:07PM +0200, Jens Remus wrote:
> Patch 1 fixes the empty GNU_EH_FRAME program table header entry to
> enable unwinders and stacktracers to locate the .eh_frame_hdr section.
> 
> Patch 2 uses symbolic constants for the PHDR permission flags to improve
> readability and explicitly specifies the GNU_EH_FRAME PHDR to be read-
> only.
> 
> Regards,
> Jens
> 
> 
> Jens Remus (2):
>   s390/vdso: Pass --eh-frame-hdr to the linker
>   s390/vdso: Use symbolic constants for the PHDR permission flags
> 
>  arch/s390/kernel/vdso/Makefile   |  3 ++-
>  arch/s390/kernel/vdso/vdso.lds.S | 12 ++++++++----
>  2 files changed, 10 insertions(+), 5 deletions(-)

This series is in limbo state. Do you plan to send a new version to
address the very minor nits, or should it stay as is?

In any case:
Acked-by: Heiko Carstens <hca@linux.ibm.com>

Re: [PATCH 0/2] s390/vdso: Fix GNU_EH_FRAME PHDR

[Jens Remus]

On 7/10/2026 9:46 AM, Heiko Carstens wrote:
> On Mon, Jul 06, 2026 at 05:19:07PM +0200, Jens Remus wrote:
>> Patch 1 fixes the empty GNU_EH_FRAME program table header entry to
>> enable unwinders and stacktracers to locate the .eh_frame_hdr section.
>>
>> Patch 2 uses symbolic constants for the PHDR permission flags to improve
>> readability and explicitly specifies the GNU_EH_FRAME PHDR to be read-
>> only.

...

>> Jens Remus (2):
>>   s390/vdso: Pass --eh-frame-hdr to the linker
>>   s390/vdso: Use symbolic constants for the PHDR permission flags
>>
>>  arch/s390/kernel/vdso/Makefile   |  3 ++-
>>  arch/s390/kernel/vdso/vdso.lds.S | 12 ++++++++----
>>  2 files changed, 10 insertions(+), 5 deletions(-)
> 
> This series is in limbo state. Do you plan to send a new version to
> address the very minor nits, or should it stay as is?

Sorry for the delay!  I have sent a v2.

I tried hard to figure out whether adding a proper GNU_STACK PHDR
with RW in a separate commit (similar to x86 commit 8717b02b8c03
("x86/entry/vdso: Include GNU_PROPERTY and GNU_STACK PHDRs") would
provide any benefit on s390:

Loading executables in the kernel:

- s390, unlike other archs, does not provide an arch-specific
  elf_read_implies_exec(), therefore the generic from include/linux/elf.h
  that returns false is used.
- As a consequence fs/binfmt_elf.c, load_elf_binary() does not default
  executables without GNU_STACK PHDR to executable stack.

Loading shared libraries in Glibc:

- elf/dl-load.c, _dl_map_object_from_fd() does default shared libraries
  without GNU_STACK PHDR to executable stack (see DEFAULT_STACK_PERMS).


Based on that I performed the following tests, all using an executable
with GNU_STACK RW (not RWX):

Library with GNU_STACK RWX loaded at startup: [stack] rwxp (exec=YES)
Library with GNU_STACK RW  loaded at startup: [stack] rw-p (exec=NO)
Library without GNU_STACK  loaded at startup: [stack] rwxp (exec=YES)

Library with GNU_STACK RWX loaded via dlopen: fails  *1)
Library with GNU_STACK RW  loaded via dlopen: [stack] rw-p (exec=NO)
Library without GNU_STACK  loaded via dlopen: fails  *1)

vDSO without GNU_STACK loaded via startup: [stack] rw-p (exec=NO)  *2)
vDSO without GNU_STACK loaded via dlopen : [stack] rw-p (exec=NO)  *3)


*1) dlopen fails with cannot enable executable stack as shared object
    requires: Invalid argument.  Regardless of glibc.rtld.execstack=1
    tunable.

*2) Linking against /usr/modules/.../vdso/vdso.so (won't be listed in
    ldd output though)

*3) dlopen("linux-vdso.so.1", RTLD_NOW);


Technically adding a GNU_STACK PHDR with RW seems to be the right
thing, although I could not construct a use case, where it would
really matter.

> In any case:
> Acked-by: Heiko Carstens <hca@linux.ibm.com>

Thanks!

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.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/