[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@xxxxxx/

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