[Bug 262378] emulators/wine-devel won't start on CURRENT due to ASLR changes

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 23 Mar 2022 18:05:08 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262378

--- Comment #11 from Damjan Jovanovic <damjan.jov@gmail.com> ---
The large mapping exists even at the start of mmap_init() in that file, and at
the start of its caller, virtual_init().

Starting at the beginning, and patching main() in loader/main.c to also dump
/proc/curproc/map, shows that the large mapping exists even at the start of
main()  :-(.

But why is that absent in my test binary?

Actually, my test binary also has that large mapping:

0x80063e000 0x82061e000 0 0 0 --- 0 0 0x0 NCOW NNC none - NCH -1

but it is situated much higher up in memory: starting at addresses around
0x80063e000 (beyond the 4th GiB), instead of around 0x62bd6000 for Wine, which
frees up 0x7ffe0000 - 0x7ffe1000 which Wine needs.

Setting kern.elf64.aslr.stack=0 seems to make that large mapping go away, so it
looks to be a FreeBSD 14-CURRENT ASLR thing after all.

Does anybody know why we allocate this 0x1ffe0000 byte long mapping when
kern.elf64.aslr.stack=1, and what determines its placement in memory? Who does
that, libc, rtld-elf, the kernel?

-- 
You are receiving this mail because:
You are the assignee for the bug.