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: <dc60d456-3f02-4076-8adf-4688cfa03aeb@gmail.com>
Date: Mon, 12 Feb 2024 09:48:30 +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 2/12/24 09:43, Bagas Sanjaya wrote:
> 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.
> 

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/x86_64/kernel/sys_x86_64.c?id=717db2f9f36805d85c695771ea7d712812896aa7

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