Re: arch/x86/kernel/sys_x86_64.c: rationale for 0x40000000 for MAP_32BIT's start address?

[Bagas Sanjaya]

On Sun, Feb 11, 2024 at 08:52:45AM +0000, hapter@xxxxxxxxxxx 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

Attachment: signature.asc
Description: PGP signature