[PATCH 0/2] sparc64: Randomize mmap base and PIE executables

[PATCH 0/2] sparc64: Randomize mmap base and PIE executables

[Stian Halseth]

On sparc64 a 64-bit process gets little address space randomization:
the stack moves, but shared libraries, anonymous mappings, PIE
executables and the brk heap land at the same address on every run.

Patch 1 makes arch_get_unmapped_area() start at the randomized
mm->mmap_base again, which it has ignored since v3.8. Patch 2 selects
ARCH_HAS_ELF_RANDOMIZE so that PIE executables and brk are randomized
as on other architectures.

Found while adding PIE support to the sparc64 Go port:
https://github.com/sparclinux/issues/issues/119

Tested on a T4-1 and a T7-1 (sun4v) and a V240 (sun4u), with 64-bit and
32-bit userland. With the series the program image, brk, shared
libraries and mmap base move between runs, and with
randomize_va_space=0 or setarch -R the layout is the same as before.
The exec and mm selftests, glibc's elf and nptl tests, the Python test
suite and a kernel build give the same results with and without the
series.

Stian Halseth (2):
  sparc64: Start bottom-up mmap searches at mm->mmap_base
  sparc64: Randomize the load address of PIE executables

 .../features/vm/ELF-ASLR/arch-support.txt      |  2 +-
 arch/sparc/Kconfig                             |  1 +
 arch/sparc/kernel/sys_sparc_64.c               | 18 ++++++++++++++----
 3 files changed, 16 insertions(+), 5 deletions(-)


base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
-- 
2.43.0

[PATCH 1/2] sparc64: Start bottom-up mmap searches at mm->mmap_base

[Stian Halseth]

arch_pick_mmap_layout() randomizes mm->mmap_base for the bottom-up
layout, which every 64-bit task uses, but arch_get_unmapped_area()
starts its search at TASK_UNMAPPED_BASE and never looks at it. Shared
libraries and anonymous mappings of 64-bit tasks therefore land at the
same address on every run; only the stack is randomized.

Before the conversion to vm_unmapped_area() the search started at
mm->free_area_cache, which binfmt_elf set to mm->mmap_base. Use
mm->mmap_base as the low limit again, as generic_get_unmapped_area()
does.

Fixes: bb64f55019c7 ("mm: use vm_unmapped_area() on sparc64 architecture")
Link: https://github.com/sparclinux/issues/issues/119
Cc: stable@vger.kernel.org
Signed-off-by: Stian Halseth <stian@itx.no>
---
 arch/sparc/kernel/sys_sparc_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index ecefcffcf7b10..087595fa43081 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -142,7 +142,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
 	}
 
 	info.length = len;
-	info.low_limit = TASK_UNMAPPED_BASE;
+	info.low_limit = mm->mmap_base;
 	info.high_limit = min(task_size, VA_EXCLUDE_START);
 	info.align_mask = get_align_mask(filp, flags);
 	if (!file_hugepage)
@@ -151,7 +151,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
 
 	if ((addr & ~PAGE_MASK) && task_size > VA_EXCLUDE_END) {
 		VM_BUG_ON(addr != -ENOMEM);
-		info.low_limit = VA_EXCLUDE_END;
+		info.low_limit = max(mm->mmap_base, VA_EXCLUDE_END);
 		info.high_limit = task_size;
 		addr = vm_unmapped_area(&info);
 	}
-- 
2.43.0

[PATCH 2/2] sparc64: Randomize the load address of PIE executables

[Stian Halseth]

On sparc64 every PIE executable (ET_DYN with PT_INTERP) is loaded at
exactly ELF_ET_DYN_BASE, with its brk heap at a fixed offset after it.
The stack and the mmap base are randomized; the program image and brk
are not.

load_elf_binary() adds arch_mmap_rnd() to the load bias and calls
arch_randomize_brk(), but without ARCH_HAS_ELF_RANDOMIZE both are
no-ops. sparc64 already has a suitable mmap_rnd() for the mmap base.
Rename it to arch_mmap_rnd(), add arch_randomize_brk() with the ranges
x86 and the generic version use, and select ARCH_HAS_ELF_RANDOMIZE.

Closes: https://github.com/sparclinux/issues/issues/119
Signed-off-by: Stian Halseth <stian@itx.no>
---
 .../features/vm/ELF-ASLR/arch-support.txt          |  2 +-
 arch/sparc/Kconfig                                 |  1 +
 arch/sparc/kernel/sys_sparc_64.c                   | 14 ++++++++++++--
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt
index 57406c0d53531..d4a34c9fbae86 100644
--- a/Documentation/features/vm/ELF-ASLR/arch-support.txt
+++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt
@@ -24,7 +24,7 @@
     |       riscv: |  ok  |
     |        s390: |  ok  |
     |          sh: | TODO |
-    |       sparc: | TODO |
+    |       sparc: |  ok  |
     |          um: | TODO |
     |         x86: |  ok  |
     |      xtensa: | TODO |
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index ab77d3f2536e1..82c989b9e7831 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -71,6 +71,7 @@ config SPARC64
 	def_bool 64BIT
 	select ALTERNATE_USER_ADDRESS_SPACE
 	select ARCH_HAS_DELAY_TIMER
+	select ARCH_HAS_ELF_RANDOMIZE
 	select HAVE_FUNCTION_TRACER
 	select HAVE_FUNCTION_GRAPH_TRACER
 	select HAVE_KRETPROBES
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 087595fa43081..2948d5769e768 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -26,6 +26,8 @@
 #include <linux/ipc.h>
 #include <linux/personality.h>
 #include <linux/random.h>
+#include <linux/elf-randomize.h>
+#include <linux/sizes.h>
 #include <linux/export.h>
 #include <linux/context_tracking.h>
 #include <linux/timex.h>
@@ -280,7 +282,7 @@ unsigned long get_fb_unmapped_area(struct file *filp, unsigned long orig_addr, u
 EXPORT_SYMBOL(get_fb_unmapped_area);
 
 /* Essentially the same as PowerPC.  */
-static unsigned long mmap_rnd(void)
+unsigned long arch_mmap_rnd(void)
 {
 	unsigned long rnd = 0UL;
 
@@ -294,9 +296,17 @@ static unsigned long mmap_rnd(void)
 	return rnd << PAGE_SHIFT;
 }
 
+unsigned long arch_randomize_brk(struct mm_struct *mm)
+{
+	if (test_thread_flag(TIF_32BIT))
+		return randomize_page(mm->brk, SZ_32M);
+
+	return randomize_page(mm->brk, SZ_1G);
+}
+
 void arch_pick_mmap_layout(struct mm_struct *mm, const struct rlimit *rlim_stack)
 {
-	unsigned long random_factor = mmap_rnd();
+	unsigned long random_factor = arch_mmap_rnd();
 	unsigned long gap;
 
 	/*
-- 
2.43.0

Re: [PATCH 0/2] sparc64: Randomize mmap base and PIE executables

[Jan Engelhardt]

On Saturday 2026-10-17 12:04, Stian Halseth wrote:

>On sparc64 a 64-bit process gets little address space randomization:
>the stack moves, but shared libraries, anonymous mappings, PIE
>executables and the brk heap land at the same address on every run.
>Tested on a T4-1 and a T7-1 (sun4v) and a V240 (sun4u), with 64-bit and

I too gave this a spin, on T5240 with a Linux 7.2.11 base and
Debian's LP64 userland.

Tested-by: Jan Engelhardt <jengelh@inai.de>

Re: [PATCH 2/2] sparc64: Randomize the load address of PIE executables

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] sparc64: 32-bit compat PIE and brk collide with TASK_UNMAPPED_BASE
--

commit 91a8982a72732f896c36479ab4e561774ee258f9
Author: Stian Halseth <stian@itx.no>

sparc64: Randomize the load address of PIE executables

This commit enables PIE load address and brk randomization on sparc64 by
renaming mmap_rnd() to arch_mmap_rnd(), adding arch_randomize_brk(), and
selecting ARCH_HAS_ELF_RANDOMIZE.

> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index ab77d3f2536e1..82c989b9e7831 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -71,6 +71,7 @@ config SPARC64
>  	def_bool 64BIT
>  	select ALTERNATE_USER_ADDRESS_SPACE
>  	select ARCH_HAS_DELAY_TIMER
> +	select ARCH_HAS_ELF_RANDOMIZE
>  	select HAVE_FUNCTION_TRACER
>  	select HAVE_FUNCTION_GRAPH_TRACER
>  	select HAVE_KRETPROBES
> diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
> index 087595fa43081..2948d5769e768 100644
> --- a/arch/sparc/kernel/sys_sparc_64.c
> +++ b/arch/sparc/kernel/sys_sparc_64.c
> @@ -26,6 +26,8 @@
>  #include <linux/ipc.h>
>  #include <linux/personality.h>
>  #include <linux/random.h>
> +#include <linux/elf-randomize.h>
> +#include <linux/sizes.h>
>  #include <linux/export.h>
>  #include <linux/context_tracking.h>
>  #include <linux/timex.h>
> @@ -280,7 +282,7 @@ unsigned long get_fb_unmapped_area(struct file *filp, unsigned long orig_addr, u
>  EXPORT_SYMBOL(get_fb_unmapped_area);
>  
>  /* Essentially the same as PowerPC.  */
> -static unsigned long mmap_rnd(void)
> +unsigned long arch_mmap_rnd(void)
>  {
>  	unsigned long rnd = 0UL;
>  
> @@ -294,9 +296,17 @@ static unsigned long mmap_rnd(void)
>  	return rnd << PAGE_SHIFT;
>  }
>  
> +unsigned long arch_randomize_brk(struct mm_struct *mm)
> +{
> +	if (test_thread_flag(TIF_32BIT))
> +		return randomize_page(mm->brk, SZ_32M);
> +
> +	return randomize_page(mm->brk, SZ_1G);
> +}

[Severity: High]
Does enabling ARCH_HAS_ELF_RANDOMIZE and arch_randomize_brk() cause 32-bit
compat PIE binaries and their brk heap to collide with TASK_UNMAPPED_BASE
when using the bottom-up mmap layout?

On sparc64, 32-bit tasks (TIF_32BIT) have COMPAT_ELF_ET_DYN_BASE and
TASK_UNMAPPED_BASE set to the same address (0x70000000UL):

arch/sparc/include/asm/elf_64.h:
    #define ELF_ET_DYN_BASE		0x0000010000000000UL
    #define COMPAT_ELF_ET_DYN_BASE	0x0000000070000000UL

arch/sparc/include/asm/page_64.h:
    #define TASK_UNMAPPED_BASE	(test_thread_flag(TIF_32BIT) ? \
    				 _AC(0x0000000070000000,UL) : \
    				 VA_EXCLUDE_END)

When a 32-bit compat task uses the bottom-up layout in
arch_pick_mmap_layout() (when RLIMIT_STACK is RLIM_INFINITY,
ADDR_COMPAT_LAYOUT is set in personality, or sysctl_legacy_va_layout is
enabled), mm->mmap_base is set to 0x70000000UL + random_factor (with
random_factor in [0, 8MB)).

With CONFIG_ARCH_HAS_ELF_RANDOMIZE selected, fs/compat_binfmt_elf.c (which
builds load_elf_binary() with ELF_ET_DYN_BASE defined as
COMPAT_ELF_ET_DYN_BASE) changes behavior in two ways for 32-bit bottom-up
tasks:

1. For 32-bit ET_DYN binaries without PT_INTERP (static PIE or direct
   invocation of ld.so), load_elf_binary() maps the binary at load_bias = 0,
   which resolves via arch_get_unmapped_area() to mm->mmap_base
   (0x70000000UL + rnd1). Then load_elf_binary() moves elf_brk:

   fs/binfmt_elf.c:load_elf_binary() {
       ...
       if (!IS_ENABLED(CONFIG_COMPAT_BRK) &&
           IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) &&
           elf_ex->e_type == ET_DYN && !interpreter) {
           elf_brk = ELF_ET_DYN_BASE;
           /* This counts as moving the brk, so let brk(2) know. */
           brk_moved = true;
       }
   }

   When ASLR is disabled or randomize_va_space is 1, mm->start_brk and
   mm->brk are set to 0x70000000UL, pointing directly at the start of the
   mapped binary and causing sys_brk() to hit the binary's own VMA and fail
   on the first heap expansion. When randomize_va_space is 2,
   arch_randomize_brk() places mm->brk in [0x70000000UL, 0x70000000UL + 32MB),
   overlapping the binary, vDSO, and bottom-up mmap region.

2. For 32-bit dynamic PIE binaries (ET_DYN with PT_INTERP) in bottom-up
   mode, load_elf_binary() randomizes load_bias to 0x70000000UL + rnd2
   (with rnd2 in [0, 8MB)), mapping the executable in the same
   [0x70000000UL, 0x70800000UL) window as mm->mmap_base. Next,
   load_elf_interp() and arch_setup_additional_pages() map ld.so and the
   vDSO bottom-up from mm->mmap_base, placing them at or shortly above
   elf_brk. Then arch_randomize_brk() advances mm->start_brk and mm->brk by
   up to SZ_32M past elf_brk without checking for existing VMAs, placing
   mm->brk inside or above ld.so/vDSO right in the middle of the bottom-up
   mmap region.

Should COMPAT_ELF_ET_DYN_BASE be separated from 32-bit TASK_UNMAPPED_BASE
(similar to powerpc, x86, and arm64, which place 32-bit COMPAT_ELF_ET_DYN_BASE
at 0x000400000UL or offset from TASK_UNMAPPED_BASE) so that 32-bit PIE and
brk do not collide with the bottom-up mmap base?

> +
>  void arch_pick_mmap_layout(struct mm_struct *mm, const struct rlimit *rlim_stack)
>  {
> -	unsigned long random_factor = mmap_rnd();
> +	unsigned long random_factor = arch_mmap_rnd();
>  	unsigned long gap;
>  
>  	/*

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261017100451.2266781-1-stian@itx.no?part=2

Re: [PATCH 2/2] sparc64: Randomize the load address of PIE executables

[Stian Halseth]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]


On Sun, 2026-10-18 at 10:05 +0000, sashiko-bot@kernel.org wrote:
> 
> Should COMPAT_ELF_ET_DYN_BASE be separated from 32-bit
> TASK_UNMAPPED_BASE (similar to powerpc, x86, and arm64, which place
> 32-bit COMPAT_ELF_ET_DYN_BASE at 0x000400000UL or offset from
> TASK_UNMAPPED_BASE) so that 32-bit PIE and brk do not collide with
> the bottom-up mmap base?
> 

Confirmed for 32-bit tasks in the legacy bottom-up layout.

The dynamic PIE case was actually broken already, brk could not grow at
all in that layout.

The explicitly executed loader case is a real regression from this
series though.

v2 will add a patch that moves COMPAT_ELF_ET_DYN_BASE below the legacy
mmap base.

I can't use the 4MB that x86, arm64 and powerpc use, though. binfmt_elf
rounds the load address down to the PIE's p_align, and from 4MB a 32-
bit PIE with 8MB or larger alignment ends up at 0 and fails to exec.
1GB keeps every alignment the old base allowed.

/Stian

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]