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

[PATCH v2 0/3] 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 moves the
32-bit PIE base out of the legacy mmap area, so that patch 3 can select
ARCH_HAS_ELF_RANDOMIZE and randomize PIE executables and brk 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.

Changes in v2:
- New patch 2: move COMPAT_ELF_ET_DYN_BASE below the 32-bit legacy mmap
  base, so a 32-bit PIE and the brk of an explicitly executed loader no
  longer land in the mmap area (Sashiko). Tested on the T4 with 32-bit
  userland, including PIEs with large p_align.
- Add Jan's Tested-by to patches 1 and 3.

v1: https://lore.kernel.org/all/20261017100451.2266781-1-stian@itx.no/

Stian Halseth (3):
  sparc64: Start bottom-up mmap searches at mm->mmap_base
  sparc64: Move the 32-bit PIE base below the legacy mmap base
  sparc64: Randomize the load address of PIE executables

 .../features/vm/ELF-ASLR/arch-support.txt      |  2 +-
 arch/sparc/Kconfig                             |  1 +
 arch/sparc/include/asm/elf_64.h                |  2 +-
 arch/sparc/kernel/sys_sparc_64.c               | 18 ++++++++++++++----
 4 files changed, 17 insertions(+), 6 deletions(-)


base-commit: 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
-- 
2.43.0

[PATCH v2 1/3] 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
Tested-by: Jan Engelhardt <jengelh@inai.de>
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 v2 2/3] sparc64: Move the 32-bit PIE base below the legacy mmap base

[Stian Halseth]

COMPAT_ELF_ET_DYN_BASE is 0x70000000, the same address as
TASK_UNMAPPED_BASE for 32-bit tasks. With the legacy bottom-up layout
the mmap area therefore starts where a 32-bit PIE is loaded, and once
ARCH_HAS_ELF_RANDOMIZE is selected binfmt_elf also moves the brk of an
explicitly executed loader there, on top of the loader itself.

Move it to 1GB. x86, arm64 and powerpc use 4MB, but binfmt_elf now
rounds the load address down to the PIE's p_align, and from a 4MB base
an alignment of 8MB or more can round it down to 0. 1GB keeps every
alignment the old base allowed and leaves room for brk below the mmap
area.

Signed-off-by: Stian Halseth <stian@itx.no>
---
 arch/sparc/include/asm/elf_64.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/include/asm/elf_64.h b/arch/sparc/include/asm/elf_64.h
index 694ed081cf8d9..3f7050369f79d 100644
--- a/arch/sparc/include/asm/elf_64.h
+++ b/arch/sparc/include/asm/elf_64.h
@@ -190,7 +190,7 @@ typedef struct {
    that it will "exec", and that there is sufficient room for the brk.  */
 
 #define ELF_ET_DYN_BASE		0x0000010000000000UL
-#define COMPAT_ELF_ET_DYN_BASE	0x0000000070000000UL
+#define COMPAT_ELF_ET_DYN_BASE	0x0000000040000000UL
 
 extern unsigned long sparc64_elf_hwcap;
 #define ELF_HWCAP	sparc64_elf_hwcap
-- 
2.43.0

[PATCH v2 3/3] 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
Tested-by: Jan Engelhardt <jengelh@inai.de>
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 v2 0/3] sparc64: Randomize mmap base and PIE executables

[John Paul Adrian Glaubitz]

Hi Stian,

On Sun, 2026-10-18 at 14:27 +0200, 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.
> 
> Patch 1 makes arch_get_unmapped_area() start at the randomized
> mm->mmap_base again, which it has ignored since v3.8. Patch 2 moves the
> 32-bit PIE base out of the legacy mmap area, so that patch 3 can select
> ARCH_HAS_ELF_RANDOMIZE and randomize PIE executables and brk 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.

What about sparc32? Does it use address base randomization at all?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Stian Halseth]

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

Hi Adrian,

On Sun, 2026-10-18 at 15:09 +0200, John Paul Adrian Glaubitz wrote:
> 
> What about sparc32? Does it use address base randomization at all?
> 

sparc32 is at the same state as sparc64 was before this series. Only
the stack moves.

I've only tested 32-bit programs on sparc64. The same approach will
probably work, but needs testing on real sparc32. Could be possibly be
added as a follow up, if someone with sparc32 hardware can test it.

/Stian


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

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

[Stian Halseth]

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


On Sun, 2026-10-18 at 15:33 +0200, Stian Halseth wrote:
> Hi Adrian,
> 
> On Sun, 2026-10-18 at 15:09 +0200, John Paul Adrian Glaubitz wrote:
> > 
> > What about sparc32? Does it use address base randomization at all?
> > 
> 
> sparc32 is at the same state as sparc64 was before this series. Only
> the stack moves.
> 
> I've only tested 32-bit programs on sparc64. The same approach will
> probably work, but needs testing on real sparc32. Could be possibly
> be
> added as a follow up, if someone with sparc32 hardware can test it.
> 
> /Stian
> 

Additionally, outside of qemu testing, I'm a bit worried about sparc32
machines with virtually indexed caches. I've heard those can be fun,
and I wouldn't feel confident about implementing it without testing on
the "real thing".

/Stian

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

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

[Magnus Lindholm]

Hi,

On Sun, Oct 18, 2026 at 3:38 PM Stian Halseth <stian@itx.no> wrote:
>
>
> On Sun, 2026-10-18 at 15:33 +0200, Stian Halseth wrote:
> > Hi Adrian,
> >
> > On Sun, 2026-10-18 at 15:09 +0200, John Paul Adrian Glaubitz wrote:
> > >
> > > What about sparc32? Does it use address base randomization at all?
> > >
> >
> > sparc32 is at the same state as sparc64 was before this series. Only
> > the stack moves.
> >
> > I've only tested 32-bit programs on sparc64. The same approach will
> > probably work, but needs testing on real sparc32. Could be possibly
> > be
> > added as a follow up, if someone with sparc32 hardware can test it.
> >
> > /Stian
> >
>
> Additionally, outside of qemu testing, I'm a bit worried about sparc32
> machines with virtually indexed caches. I've heard those can be fun,
> and I wouldn't feel confident about implementing it without testing on
> the "real thing".
>

Stian, following your exchange with Adrian, would you be willing to put
together a native sparc32 version? I can test it  on my Hypersparc SS-20.

Thanks,
Magnus

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

[Stian Halseth]

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

Hi Magnus,

On Sun, 2026-10-18 at 22:37 +0200, Magnus Lindholm wrote:
> > 
> > Additionally, outside of qemu testing, I'm a bit worried about
> > sparc32
> > machines with virtually indexed caches. I've heard those can be
> > fun,
> > and I wouldn't feel confident about implementing it without testing
> > on
> > the "real thing".
> > 
> 
> Stian, following your exchange with Adrian, would you be willing to
> put
> together a native sparc32 version? I can test it  on my Hypersparc
> SS-20.
> 
Sure, I could do that. 

Ideally, I would like to get this sparc64 series through review before
I add anything else. Could be a follow up series based on this one.

/Stian


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

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

[Magnus Lindholm]

Hi Stian,

On Sun, Oct 18, 2026 at 11:08 PM Stian Halseth <stian@itx.no> wrote:
>
> Hi Magnus,
>
> On Sun, 2026-10-18 at 22:37 +0200, Magnus Lindholm wrote:
> > >
> > > Additionally, outside of qemu testing, I'm a bit worried about
> > > sparc32
> > > machines with virtually indexed caches. I've heard those can be
> > > fun,
> > > and I wouldn't feel confident about implementing it without testing
> > > on
> > > the "real thing".
> > >
> >
> > Stian, following your exchange with Adrian, would you be willing to
> > put
> > together a native sparc32 version? I can test it  on my Hypersparc
> > SS-20.
> >
> Sure, I could do that.
>
> Ideally, I would like to get this sparc64 series through review before
> I add anything else. Could be a follow up series based on this one.
>

Agree, no need to mess with this series while it's in flight.

Magnus