linux-kernel - Re: [PATCH RFC v2 1/4] mm: Add MAP_BELOW

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: <87mskvenum.fsf@mail.lhotse>
Date: Thu, 29 Aug 2024 18:26:41 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Charlie Jenkins <charlie@...osinc.com>, Arnd Bergmann <arnd@...db.de>,
 Richard Henderson <richard.henderson@...aro.org>, Ivan Kokshaysky
 <ink@...assic.park.msu.ru>, Matt Turner <mattst88@...il.com>, Vineet Gupta
 <vgupta@...nel.org>, Russell King <linux@...linux.org.uk>, Guo Ren
 <guoren@...nel.org>, Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui
 <kernel@...0n.name>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
 "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>, Helge
 Deller <deller@....de>, Nicholas Piggin <npiggin@...il.com>, Christophe
 Leroy <christophe.leroy@...roup.eu>, Naveen N Rao <naveen@...nel.org>,
 Alexander Gordeev <agordeev@...ux.ibm.com>, Gerald Schaefer
 <gerald.schaefer@...ux.ibm.com>, Heiko Carstens <hca@...ux.ibm.com>,
 Vasily Gorbik <gor@...ux.ibm.com>, Christian Borntraeger
 <borntraeger@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>,
 Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich Felker
 <dalias@...c.org>, John Paul Adrian Glaubitz
 <glaubitz@...sik.fu-berlin.de>, "David S. Miller" <davem@...emloft.net>,
 Andreas Larsson <andreas@...sler.com>, Thomas Gleixner
 <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Peter
 Zijlstra <peterz@...radead.org>, Muchun Song <muchun.song@...ux.dev>,
 Andrew Morton <akpm@...ux-foundation.org>, "Liam R. Howlett"
 <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>, Lorenzo
 Stoakes <lorenzo.stoakes@...cle.com>, Shuah Khan <shuah@...nel.org>
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-alpha@...r.kernel.org, linux-snps-arc@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org,
 loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
 linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
 linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
 sparclinux@...r.kernel.org, linux-mm@...ck.org,
 linux-kselftest@...r.kernel.org, Charlie Jenkins <charlie@...osinc.com>
Subject: Re: [PATCH RFC v2 1/4] mm: Add MAP_BELOW_HINT

Charlie Jenkins <charlie@...osinc.com> writes:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the hint address uses more than 47 bits (the 48th bit is reserved
> for the kernel address space).
>
> To make this behavior explicit and more versatile across all
> architectures, define a mmap flag that allows users to define an
> arbitrary upper limit on addresses returned by mmap.
>
> Signed-off-by: Charlie Jenkins <charlie@...osinc.com>
> ---
>  include/uapi/asm-generic/mman-common.h       | 1 +
>  tools/include/uapi/asm-generic/mman-common.h | 1 +

You're not meant to update the headers in tools/ directly. There's a
mail somewhere from acme somewhere describing the proper process, but
the tldr is leave it up to him.

> diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
> index 6ce1f1ceb432..03ac13d9aa37 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -32,6 +32,7 @@
>  
>  #define MAP_UNINITIALIZED 0x4000000	/* For anonymous mmap, memory could be
>  					 * uninitialized */
> +#define MAP_BELOW_HINT	  0x8000000	/* give out address that is below (inclusive) hint address */

IMHO the API would be clearer if this actually forced the address to be
below the hint. That's what the flag name implies after all.

It would also mean the application doesn't need to take into account the
length of the mapping when passing the hint.

cheers