linux-kernel - Re: arch/x86/kernel/sys_x86_64.c: rationale for 0x40000000 for 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: <ZcmF3SrTACMULEPb@archie.me>
Date: Mon, 12 Feb 2024 09:43:41 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: hapter@...blaze.it, mingo@...hat.com
Cc: tglx@...utronix.de, bp@...en8.de, dave.hansen@...ux.intel.com,
	x86@...nel.org, hpa@...or.com, Andi Kleen <ak@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: arch/x86/kernel/sys_x86_64.c: rationale for 0x40000000 for
 MAP_32BIT's start address?

On Sun, Feb 11, 2024 at 08:52:45AM +0000, hapter@...blaze.it wrote:
> I've found that passing in MAP_32BIT for mmap() will always return an
> address above 0x40000000. The problem seems to lie in
From one gigabyte up?
> arch/x86/kernek/sys_x86_64.c, where the following comment is the only thing
> close to a hint(Line 100):
> 
> /* This is usually used needed to map code in small
>    model, so it needs to be in the first 31bit. Limit
>    it to that.  This means we need to move the
>    unmapped base down for this case. This can give
>    conflicts with the heap, but we assume that glibc
>    malloc knows how to fall back to mmap. Give it 1GB
>    of playground for now. -AK */
> 
> Unfortunately this does not supply a rationale for starting from 0x40000000,
> which seems very arbitrary, and the git commit has been there since the
> beginning of time (i.e. as far the the git history goes), so the git blame
> has not helped much to clarify it. I was also not able to find who "AK" was.

That was from commit 717db2f9f36805 ("[PATCH] x86-64 updates for 2.5.54")
in tglx/history.git repo [1], authored by Andi Kleen. Cc'ing him.

> 
> I have found another operating system that provides MAP_32BIT, FreeBSD, to
> not exhibit the same behavior and not cause any execution problems for RWX
> pages allocated below 0x40000000, so it does not seem a technical rationale
> exists either.
> 
> mmap will happily return 0x10000 (which seems like the lowest address the
> kernel will map when you supply it as a hint, so I do not see any reason not
> to start the find from 0x10000, or something that isn't as big as
> 0x40000000, which is big enough to impose a significant handicap for
> applications using MAP_32BIT (e.g. JITs that want to use CALL rel32 at all
> times).
> 

Confused...

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)