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
