linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <focr7orndhsr7vhownfdhrpctwztloz54bfbg2wnd4xmqtcymu@26pn5wteugl6>
Date: Wed, 11 Sep 2024 15:48:43 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Helge Deller <deller@...nel.org>
Cc: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
        linux-mm@...ck.org, linux-parisc@...r.kernel.org
Subject: Re: [PATCH] [RFC] mm: mmap: Allow mmap(MAP_STACK) to map growable
 stack

* Helge Deller <deller@...nel.org> [240911 15:20]:
> 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     ) |

Right now MAP_STACK can be used to set VM_NOHUGEPAGE, but this will
change the user interface to create a vma that will grow.  I'm not
entirely sure this is okay?


That is mmap(MAP_STACK) would set VM_NOHUGEPAGE right now, with this
change you'd get VM_NOHUGEPAGE | VM_GROWS<something>

>  	       _calc_vm_trans(flags, MAP_STACK,	     VM_NOHUGEPAGE) |
>  	       arch_calc_vm_flag_bits(flags);
>  }
>