linux-kernel - [PATCH] [RFC] mm: mmap: Allow mmap(MAP

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZuHtb43Ar21ZptNz@p100>
Date: Wed, 11 Sep 2024 21:20:15 +0200
From: Helge Deller <deller@...nel.org>
To: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
	linux-mm@...ck.org
Cc: linux-parisc@...r.kernel.org
Subject: [PATCH] [RFC] mm: mmap: Allow mmap(MAP_STACK) to map growable stack

This is a RFC to change the behaviour of mmap(MAP_STACK) to be
sufficient to map memory for usage as stack on all architectures.
Currently MAP_STACK is a no-op on Linux, and instead MAP_GROWSDOWN
has to be used.
To clarify, here is the relevant info from the mmap() man page:

MAP_GROWSDOWN
   This flag is used for stacks. It indicates to the kernel virtual
   memory system that the mapping should extend downward in memory.  The
   return address is one page lower than the memory area that is
   actually created in the process's virtual address space.  Touching an
   address in the "guard" page below the mapping will cause the mapping
   to grow by a page. This growth can be repeated until the mapping
   grows to within a page of the high end of the next lower mapping,
   at which point touching the "guard" page will result in a SIGSEGV
   signal.

MAP_STACK (since Linux 2.6.27)
   Allocate the mapping at an address suitable for a process or thread
   stack.

   This flag is currently a no-op on Linux. However, by employing this
   flag, applications can ensure that they transparently obtain support
   if the flag is implemented in the future. Thus, it is used in the
   glibc threading implementation to allow for the fact that
   some architectures may (later) require special treatment for
   stack allocations. A further reason to employ this flag is
   portability: MAP_STACK exists (and has an effect) on some
   other systems (e.g., some of the BSDs).

The reason to suggest this change is, that on the parisc architecture the
stack grows upwards. As such, using solely the MAP_GROWSDOWN flag will not
work. Note that there exists no MAP_GROWSUP flag.
By changing the behaviour of MAP_STACK to mark the memory area with the
VM_STACK bit (which is VM_GROWSUP or VM_GROWSDOWN depending on the
architecture) the MAP_STACK flag does exactly what people would expect on
all platforms.

This change should have no negative side-effect, as all code which
used mmap(MAP_GROWSDOWN | MAP_STACK) still work as before.

Signed-off-by: Helge Deller <deller@....de>

diff --git a/include/linux/mman.h b/include/linux/mman.h
index bcb201ab7a41..66bc72a0cb19 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -156,6 +156,7 @@ calc_vm_flag_bits(unsigned long flags)
 	return _calc_vm_trans(flags, MAP_GROWSDOWN,  VM_GROWSDOWN ) |
 	       _calc_vm_trans(flags, MAP_LOCKED,     VM_LOCKED    ) |
 	       _calc_vm_trans(flags, MAP_SYNC,	     VM_SYNC      ) |
+	       _calc_vm_trans(flags, MAP_STACK,      VM_STACK     ) |
 	       _calc_vm_trans(flags, MAP_STACK,	     VM_NOHUGEPAGE) |
 	       arch_calc_vm_flag_bits(flags);
 }